bi-09 — Broader Ideas
Record, then execute
Paint produces a display list rather than pixels. That indirection buys: rastering off the main thread, rastering at a different scale, reusing output, and applying property changes without re-recording.
The same pattern, elsewhere:
| System | Recording | Executor |
|---|---|---|
| Blink paint | display list | raster / GPU |
| Compositor | CompositorFrame (quads) | viz / DirectRenderer |
| Virtual DOM | element tree | reconciler |
| SQL | query plan | execution engine |
| Graphics APIs | command buffer | GPU |
Separating description from execution is what makes optimisation, caching, and relocation possible. When you find yourself unable to move work off a thread or cache it, ask whether the work is expressed as instructions or as immediate effects.
Structure disguised as style
opacity: 0.99 creating a stacking context is the canonical example of a visual property with a
structural consequence. The list of stacking-context triggers is long and includes properties
people add for aesthetics.
The general caution: in declarative systems, some properties change the evaluation structure, not just the output. Knowing which is the difference between debugging z-index in ten seconds and in an afternoon.
Take this to your animation guidance
Replace "animate transform and opacity because the GPU is fast" with the pipeline explanation.
It predicts the exceptions correctly — filter: blur() is composited and still expensive — and a
hardware explanation cannot.
Next
bi-10 takes the display list and produces frames; fw-10 is where paint cost and DOM size meet in
application code.