I am struggling to grok requestanimationframe.
Is it correct to say that requestanimationframe is a browser API that enables logic that affects the painted user-interface to be run in a best-effort attempt to complete before the next blitting of the interface to the graphics subsystem, so as to avoid wasted effort painting frames that never make it to the screen due to phase differences between the physical screen refresh cycle and application rendering loop?
The requestAnimationFrame is just a method which:
The requestAnimationFrame method is used to signal to the user agent that a script-based animation needs to be resampled.
When the method is called:
When requestAnimationFrame(callback) is called, the user agent MUST schedule a script-based animation resampling by appending to the end of the animation frame request callback list an entry whose handle is a user-agent-defined integer greater than zero that uniquely identifies the entry in the list and whose callback is callback.
The next step is to go through the callback list (unless a cancelAnimationFrame has been called for one or more of the IDs still in the list) before the browser issues a repaint.
The Window.requestAnimationFrame() method tells the browser that you wish to perform an animation and requests that the browser call a specified function to update an animation before the next repaint.
rAF will synchronize each callback so that each repaint fits the monitor's (or rather display card's) update rate (VBLANK). This basically means a new callback is issued right after a VBLANK has occurred so that the script has about 16.7ms to complete its rendering before next VBLANK triggers.
A setTimeout/setInterval is unable to synchronize with the monitor update as they can only take integer values. The usual update rate requires 16.67ms per frame @ 60 Hz, so you will get "jerks" from time to time using one of these methods as you would need to use either 16 or 17ms update rates.
rAF is not constricted by this. Since rAF is dealing with frame update list rather than the common event list, the browser can more efficiently purge the queue. The browser can also reduce the rate to f.ex. half if the browser tab is non-visible reducing the callbacks to half, which in turn reduces load.
There is no requirement to use the graphics sub-system to "blit"/repaint, but this is usually the case.
来源：https://stackoverflow.com/questions/29430789/understanding-requestanimationframe