Rendering Performance from the Ground Up
summary
Explains why painting is the slow step and how GPUs and compositing avoid it: parsing → DOM/CSSOM → layout → paint → composite, with 60 fps ≈ 16 ms per frame and a Full HD frame as ≈6.2 MB (3.2 floppy). Uses DevTools’ repaint flashing and timeline to show a menu demo that either repaints or becomes composited via will-change, demonstrates transform-only keyframe animations get layer promotion and smoothness, and warns about memory cost and browser differences (opacity and filters may still force paints).
AI-written summary · about
chapters (11)
- 0:00Start
- 1:38WHAT I DO - 3D.IO
- 2:36FROM SOURCE CODE TO PIXELS 1/2
- 4:27PARSE - LAYOUT - PAINT!
- 5:17WHAT'S PAINTING? • Screen= Array
- 7:57HOW DOES IT WORK?
- 9:31CPU VS GPU
- 12:26NOW, WHAT'S A SHADER?
- 15:13BROWSERS...
- 15:46AN EXAMPLE
- 16:54THERE'S A LOT GOING ON
related talks
58mRendering performance from the ground up
37mRendering performance inside out
42mRendering performance from the ground up
25mA visual guide of rendering performance
59mRendering Performance
28mHow to Achieve Performing Rendering in the Browser
32mParallax Performance
31mJank Busters - Chrome Rendering Performance