How Chrome’s RenderingNG Structures Drive Modern Web Rendering

The previous articles introduced RenderingNG’s goals and top‑level components; this piece dives into the key data structures that flow through the rendering pipeline.

1. Frame Trees

Frame trees consist of local and remote frames that represent each web document’s rendering process and Blink renderer. Chrome may render cross‑origin frames in separate processes, creating remote frames that contain only minimal placeholder information such as size.

2. Immutable Fragment Tree

The immutable fragment tree is the output of the layout stage, representing the position and size of every element (without transforms). Each fragment corresponds to a part of a DOM element; after layout the fragments become immutable, allowing reuse in incremental updates and parallel layout.

Restrictions such as no upward pointers and no bubbling of data enable efficient reuse of fragments across layout passes.

3. Property Trees

Property trees encode visual and scrolling effects applied to DOM elements. Four independent trees exist for each document: transform, clip, effect, and scroll. They answer where an element is on the screen, its size, and the sequence of GPU operations needed to apply visual effects.

4. Display Lists and Paint Chunks

Display lists contain low‑level drawing commands that Skia rasterizes. Paint chunks group display items that share the same property‑tree state. The rasterizer can reuse unchanged display items across frames, and whole chunks can be merged into compositor layers when appropriate.

<div style="background:green; width:80px;">Hello world</div>
<div id="blue" style="width:100px; height:100px; background:blue; position:absolute; top:0; left:0; z-index:-1;"></div>

5. Compositor Frames

Compositor frames package surfaces, render surfaces, and GPU texture tiles for GPU drawing. They are generated from the roots of local frame‑tree fragments and aggregated by Viz. Surfaces are identified by IDs; other frames embed them via surface draw quads.

By dividing the viewport into tiles, the compositor can update only the changed tiles, reducing the cost of rasterizing the entire viewport on every scroll.

Overall, these structures enable Chrome to perform layout, painting, and compositing efficiently, supporting features such as site isolation, incremental updates, and Core Web Vitals measurements.