Paint & Compositing

Paint commands, layers, the compositor thread and the frame budget. Why `transform` and `opacity` are often cheaper to animate, stated as a mechanism rather than a slogan.

Paint Commands

Painting does not produce pixels directly: it records an ordered list of drawing commands per layer, which a rasteriser later turns into bitmaps.

Q · When the browser "paints", what is it actually producing, and why does filling the same rectangle sometimes cost ten times more than filling it a different way?
Compositing Layers

A layer is a separately rasterised surface the compositor can transform and blend on its own thread — powerful, conditional, and paid for in memory.

Q · What is a compositing layer, what causes one to exist, and what does the compositor get to do with it that the main thread would otherwise have to?
Cheap and Expensive Animation

Why `transform` and `opacity` can be driven by the compositor without the main thread — stated as a mechanism, with the conditions under which it is simply not true.

Q · What actually makes an animated property cheap, and when does the advice to animate `transform` and `opacity` stop being correct?
The Frame Budget
▶ lab

A display refreshing 60 times a second gives roughly 16.7ms per frame — a useful baseline that shrinks on faster displays and is shared with the browser's own work.

Q · How much time does a frame actually give me, and how much of it is genuinely mine?
Scroll and Input Latency

Scrolling is handled by the compositor when it can be, and by the main thread when your code forces it — which is why one listener can make a whole page feel broken.

Q · Why does scrolling stay smooth on a busy page sometimes and stutter badly other times, and what decides which?
Layer Explosion

Promoting everything with `will-change` trades main-thread paint for GPU memory and per-frame compositing — and past a small number of layers that trade inverts.

Q · If layers make animation cheap, why does adding `will-change` to more elements make the page slower?