vocab.design

motion · perceived-performance

Compositor-only animation

also called GPU-accelerated animation (community), cheap properties (community), transform and opacity only (community), will-change (css), hardware acceleration (community)

An animation limited to properties the compositor can handle alone, usually transform and opacity, so it keeps running even when the main thread is busy.

A browser draws a page in stages: it works out where boxes go, paints them into layers, and then composites those layers into the picture that reaches the screen. The first two stages belong to the main thread, the one that also runs every line of script. The last one does not. If an animation only changes things the compositor can decide by itself, the whole move can be handed over once and then advanced without the main thread being consulted again. In practice that means transform and opacity, which is why the shorthand for this idea is often just “transform and opacity only”.

The payoff is what happens when the main thread is stuck. A long task, a burst of layout, a few hundred rows being built: any of these blocks the thread for tens or hundreds of milliseconds, and anything animated from script or from a layout-affecting property simply stops being redrawn until the thread comes back. That stutter has a name of its own, jank, and this is the escape it points to. The same slide written with left holds still through the stall and then jumps; written with translate it keeps gliding, because nothing in that stall was ever the compositor’s problem.

The property list is shorter than people hope. transform and opacity are the reliable pair; filter and backdrop-filter are compositable in most engines, and a handful of scroll-driven and view-transition animations get similar treatment. Everything that changes geometry (left, top, width, height, margin, padding) forces layout on every frame, and box-shadow, background-color and border-radius force paint. A useful sanity check is whether the animated value could change the position of any other element: if it could, the compositor cannot be trusted with it alone.

will-change is the way to ask for the layer before the animation starts, so the promotion does not happen inside the first frame. It is a hint with a real cost, since every promoted layer is memory the compositor holds, so it belongs on the few elements about to move and comes off when they stop. The deeper caveat is that smoothness here is a local fix. A compositor animation glides beautifully over a main thread that has stopped answering clicks, and the reader still cannot use the page. It buys the motion, not the responsiveness.

Which word?

If you wantsay
motion must stay smooth under loadcompositor-only animation
naming why smooth-looking motion feels wrongjank
an animation stutters and the cause is the code, not the curvelayout thrashing

Related

See also: Frame rate

Sources