requestidlecallback | Cooperative Scheduling of Background Tasks | Job Scheduling library

So I changed your markup a little bit:

Cooperative Scheduling of Background Tasks says:

During an idle period the user agent will run idle callbacks in FIFO order until either the idle period ends or there are no more idle callbacks eligible to be run. As such, the user agent will not necessarily run all currently posted idle callbacks within a single idle period. Any remaining idle tasks are eligible to run during the next idle period.

Therefore, I believe with your example, fnOne, fnTwo and fnThree would be executed in that order.

So Idea is behind setInterval and Sockets, setInterval is supported in most browsers and javascript WbsocketApi is supported in almost everybrowser.

Brief overview: setInterval() - this function behaviour is following when your computer is at sleep/suspended/hibernate mode it is paused and when you are at awaken mode it resumes itself.

The following code does the following, at first(maybe at the same time but) it starts php server_socket listening to the connections,

than javascript websocket api sends current timestamp in Unix timestamp milliseconds in every 2 seconds you can have 1 second it is up to you.

after that php server socket is getting this time and checks if it has anything like previous time to compare, when the code is first instantiated php does not has anything like previous time to compare it to the time which was sent from javascript websocket, so php does nothing but saves this time in the session called 'prev_time' and waits for another time data to be recieved from javascript socket, so here begins second cycle. when php server socket new time data from javascript WebsocketApi it checks it has anything like previous time to compare to this newly received time data, it means that php checks if session called 'prev_time' exists, as we are in the second cycle php discovers that it exists, grabs it's value and does following $diff = $new_time - $prev_time, $diff will be 2 seconds or 2000 miliseconds because remember our setInterval cycle happens in every 2 seconds and time format we are sending is in miliseconds,

than php checks if($diff<3000) if difference is less than 3000 if it is it knows that user is active, again you can manipulate this seconds as you wish, I choose 3000 because possible latency in the network which is almost impossible but you know I am always cautious when it comes to networks, so let's continue, when php determines that user is active php just resets 'prev_time' session with the value of $new_time which was newly received and just for testing purposes it sends message back to javascript socket,

but if $diff is more than 3000 it means that something paused our setInterval and there is only way it can happen and I think you already know what I am saying, so in the else logic of ( if($diff<3000) ) you can logout user by destroying specific session and if you want to redirect you can send some text to javacript socket and create a logic which will execute window.location = "/login" depending on the text, that's it here is the code:

First it is index.html file just to load javascript:

That's my solution. I don't know if it's "good" or if it breaks some rules of react or reselect, but it works. Maybe you can assess that?
The code is simplified to improve readability.

The idea is, the selector returns a Promise and I call requestAnimationFrame before computing the data to get a chance to refresh the ui.

selector.js:

Although this question is a little bit older, I want to answer it because I often see scripts, where a lot of these techniques are misused.

In general all your asked tools (rAF, rIC and passive listeners) are great tools and won't vanish soon. But you have to know why to use them.

Before I start: In case you generate scroll synced/scroll linked effects like parallax effects/sticky elements, throttling using rIC, setTimeout doesn't make sense because you want to react immediately.

rAF gives you the point inside the frame life cycle right before the browser wants to calculate the new style and layout of the document. This is why it is perfect to use for animations. First it won't be called more often or less often than the browser calculates layout (right frequency). Second it is called right before the browser does calculate the layout (right timing). In fact using rAF for any layout changes (DOM or CSSOM changes) makes a lot of sense. rAF is synced with the V-SYNC as any other layout rendering related stuff in the browser.

The default example of Paul Lewis looks like this:

I am not totally sure if I got correctly your questions and all your statements but I will try to give you an answer:

• Am I missing something or is this a valid test? If it's invalid, how could I test correctly?

It is a valid test if you are measuring the number of times a function has been called, this will of course depend on the browser, SO, if is GPU enhanced and some other benchmark parameters that has been commented in your question already.

If we consider that measurement correct then it can be said that by using timeouts or requestAnimationFramework could save time because we are basically following the principles of debouncing or throttling. Basically we do not want to request or called a function more times than is needed. In the case of the timer we will queue less functions calls and in the case of requestAnimationFrame because it enqueue calls before repainting and will execute them sequentially. In timeouts it could happen that calculations overlap if they are very heavy.

I found a better answer in why using requestAnimationFrame explaining the main problems with animations in the browser like Shear, flickering or frame skip. It also includes a good demo.

I think your testing method is correct, you also should interpret it correctly, maybe calls are close to be the same number because of your hardware and your engine, but as said, debounce and throttling are a performance relieve.

Here also one more article supporting not attach handlers to window scroll from Twitter. (Disclaimer: this article is from 2011 and browsers have deal with optimizations for scroll in different ways).

• why is everyone nervous about onscroll? If fluid animations require 5000 calculations over the complete site, there's no way to change it anyway?

I do not think there is nervousness in the performance hit, but the user experience will be worst for the above mentioned animation problems that your overcalling of scroll can cause, or even if there is a desynchronization with your timer you could still get the same 'performance' problems. People just recommend saving calls to scroll because: Human visual permanence doesnt require a super high frame rate and so it is useless to try to show images more often. For more complex calculations or heavy animations browsers are already working on optimizations, like you have check, some browsers had optimize this things in comparison with the 2, 3 or 6 years ago the articles you expose were written.

The standard bind method can do this:

The spec supports your assumption. In Start an idle period algorithm it says:

1. Let deadline be a time in the future until which the browser expects to remain idle. The user agent should choose deadline to ensure that no time-critical tasks will be delayed even if a callback runs for the whole time period from now to deadline. As such, it should be set to the minimum of: the closest timeout in the list of active timers as set via setTimeout and setInterval; the scheduled runtime for pending animation callbacks posted via requestAnimationFrame; pending internal timeouts such as deadlines to start rendering the next frame, process audio or any other internal task the user agent deems important.

(my emphasis)

So if there were an internal pending timeout to render the next frame, the deadline would have to be before then.

The instrumentation for these Input Latency events is pretty sophisticated and cool. These are great questions.

Input Latency events end time

Input Latency events end around the VSYNC, assuming that the work they triggered caused an invalidation that required a screen update. This is why, in your screenshot, Key Down extends much farther than Key Up. (Even if there were keyup listeners, they didn't invalidate styles/layout)

It's certainly possible there is an earlier paint & VSYNC that these events terminate at, which isn't really when the screen updates with the response to the input... but you'll have to make that call on your own.

Gray dotted lines, vsync, swap buffers

The gray dotted lines are frame boundaries, but it starts to get tricky here. In Chrome (and AFAIK, other browsers too) there are main thread frames and compositor thread frames. DevTools attempts to display a single timeline of frames to keep things simple, so it can't be perfect. For your purposes, I would look at the right edge of the screenshots in that Frames track. The right edge is where the screen updated with those contents. On Chrome we call this time swapBuffers. (VSYNC is technically when the monitor says "I'm ready for a new frame", which is slightly different)

Measuring this in JavaScript

Unfortunately, you don't have the perfect tools to pull this off. The old technique is a double-rAF, and sometimes subtract some time. At this point you definitely know there's been one new frame. Applying some of this knowledge, you could probably be pretty smart. But it wont be perfect. For example, long image decodes will delay the compositor in shipping the frame, but the main thread is now idle and VSYNC will cause it to begin a brand new frame (thus calling rAF again).

The Long Task API could help as it describes what sort of work is taking a while on the main thread. But I don't think it'll have the sort of precision we need to answer these questions. Frame Timing would have, but it died because of privacy reasons.

TDLR:

Use the timestamp from the input event, as it's taken when the input was received at the compositor. And then use some single-rAF, double-rAF mechanism, subtracting some amount of time, to approximate when the frame was shipped. And holler when you have something you're happy with; I'm interested.