BeginMainFrame, compositor-driven animations, and GPU memory

A CSS animation keeps running smoothly at 60 fps while the main thread is blocked for 400 ms parsing a JSON blob. A rAF animation on the same element freezes for the same 400 ms. Same hardware, same property, opposite results — because one hands control to the compositor, the other does not.

The BeginMainFrame handshake

In Chromium’s renderer process, the compositor thread is the driver and the main thread is the worker. The flow each vsync:

1. Compositor sends BeginMainFrame to the main thread
2. Main thread runs all per-frame work: rAF callbacks, style, layout, paint setup
3. Main thread sends CommitMainFrame back, handing off a new layer tree
4. Compositor asks raster workers to fill any dirty tiles with bitmaps
5. Compositor performs the GPU draw and displays the frame

If the main thread is too slow, the compositor does not wait: it ships the previous frame’s layer tree again (a “drawn but stale” frame). The user perceives this as a missed input or a stutter.

BeginMainFrame arrives every ~16.67 ms whether the main thread is ready or not. This is the deep reason main-thread work cannot exceed the frame budget: the metronome is relentless.

Compositor-driven CSS animations

When you write a CSS animation that only changes transform or opacity on a compositor-promoted element, the browser detects this at animation-start and hands the animation’s timeline directly to the compositor thread. From that point the main thread is not involved at all — the compositor interpolates the value frame-by-frame and renders the next bitmap directly.

This is why a CSS animation can keep running smoothly even when the main thread is completely blocked (alert dialog, long synchronous parse, debugger pause): the compositor still runs.

The same animation written in JS via rAF cannot do this, because rAF runs on the main thread. A blocked main thread freezes the rAF animation.

Compositor-driven CSS animations are the only way to guarantee animation continuity under main-thread pressure.

GPU memory exhaustion and layer eviction

Layers are not free. Each layer is a GPU bitmap costing width × height × 4 bytes. On a phone with 256 MB of GPU memory, fifty 1080p layers exhausts the budget. When the OS starts evicting tiles:

1. Browser detects the evicted tiles
2. Raster workers re-rasterise them on the fly
3. While rasterising, the compositor composites with incomplete tiles
4. The page stutters — often worse than if no layers were requested at all

The will-change anti-pattern causes this: will-change: transform on every component permanently reserves a layer per instance. A list of 100 cards each with 5 will-change’d sub-elements holds 500 layers.

The correct pattern: set will-change just before the animation starts (on mouseenter, or in a transitionstart listener), remove it on animationend or transitionend. This keeps GPU memory near zero when the user is not actively interacting.