How requestAnimationFrame Works Under the Hood in Chrome: A Deep Dive

Most developers now use

requestAnimationFrame

for JavaScript animations, but before its introduction the only options were

setTimeout

or

setInterval

, which suffer from timing inaccuracies, over‑rendering, and lack of synchronization with the browser’s rendering loop.

The core issue is timing:

setTimeout

and

setInterval

provide fixed‑interval timers without knowledge of when the browser is ready to render the next frame. The browser, however, can determine the optimal moment for a new frame, and

requestAnimationFrame

bridges this gap by letting the engine schedule callbacks at the right time.

In Chrome (based on Android 4.4), the implementation is surprisingly simple. When a script calls

requestAnimationFrame(callback)

, the engine creates a

ScriptedAnimationController

instance and registers the callback:

<code>int Document::requestAnimationFrame(PassRefPtr&lt;RequestAnimationFrameCallback&gt; callback)</code>

The controller stores callbacks, checks that the page is visible, and ensures they are only executed on the next animation frame. It also guards against background tabs:

<code>if (!page()) return;
view->serviceScriptedAnimations(monotonicFrameBeginTime);</code>

When the browser is ready to paint a new frame, it walks a call stack that eventually reaches

PageWidgetDelegate::animate

or

WebViewImpl::animate

. These functions invoke

serviceScriptedAnimations

, which iterates over the pending callbacks, converts the high‑resolution time to the appropriate base (legacy or modern), and calls each callback’s

handleEvent

method.

After callbacks run, the controller removes any that have fired or been cancelled and, if more callbacks remain, schedules another animation frame. The scheduling logic uses

base::Time

and

base::TimeDelta

to target 60 FPS when vsync is enabled, otherwise it runs as fast as possible.

Key steps of the mechanism are:

Register the callback with

requestAnimationFrame

.

The browser’s render loop triggers

animate

during a frame update.

animate

calls the controller, which executes all registered callbacks.

This ownership transfer of frame timing to the browser kernel synchronizes animation updates with rendering, avoids desynchronization, and gives the browser room to optimize.

Various entry points such as

RenderWidget::didInvalidateRect

or

RenderWidget::CompleteInit

can request an animation check, ensuring that any change that might affect the visual output schedules a new frame.

The following diagram (from the official spec) illustrates the overall flow of

requestAnimationFrame

:

Note: RenderWidget lives in content/renderer/render_widget.cc , not in core/rendering/RenderWidget.cpp . The author was initially confused because the latter contains no animation code.

In summary,

requestAnimationFrame

works by delegating the timing of animation callbacks to the browser’s rendering engine, which registers callbacks, fires them at the optimal moment, and reschedules as needed, providing smoother and more efficient animations than traditional timers.