Critical Rendering Path: Compositing

How the compositor thread assembles rasterized layers into compositor frames and coordinates with the Viz process to display the final pixels on screen.

Abstract

Compositing solves a fundamental constraint: the main thread cannot simultaneously execute JavaScript and produce visual updates. Chromium’s solution is a multi-threaded architecture where the compositor thread (cc) operates independently, enabling smooth scrolling and animations even when JavaScript blocks the main thread.

Core mental model:

1
Main Thread Tree (authoritative) → Commit → Pending Tree → Activate → Active Tree → Compositor Frame → Viz
2
       ↑                                        ↑ rasterization          ↑ drawing
3
       │                                        │ must complete          │ always responsive
4
       └── Writes only ──────────────────────── └── Never blocks ────────┘

The key architectural decisions:

The compositor thread never makes blocking calls to the main thread—this one-directional dependency is what guarantees responsiveness.

The Chrome Compositor (cc)

The cc component (Chrome Compositor) is Chromium’s multi-threaded compositing system. It runs in both the renderer process (where Blink is the client) and the browser process (for UI compositing).

Architecture Overview

1
┌─────────────────────────────────────────────────────────────────┐
2
│                      Renderer Process                            │
3
├─────────────────────────────────────────────────────────────────┤
4
│  Main Thread                    │  Compositor Thread (cc)        │
5
│  ────────────────────           │  ──────────────────────        │
6
│  • LayerTreeHost                │  • LayerTreeHostImpl           │
7
│  • Layer (public API)           │  • LayerImpl (internal)        │
8
│  • Property trees (source)      │  • Property trees (copy)       │
9
│                                 │  • TileManager                 │
10
│         │                       │  • Scheduler                   │
11
│         │ Commit (blocking)     │         │                      │
12
│         └──────────────────────▶│         │                      │
13
│                                 │         ▼                      │
14
│                                 │  CompositorFrame               │
15
│                                 │         │                      │
16
└─────────────────────────────────┼─────────┼──────────────────────┘
17
                                  │         │ IPC
18
                                  │         ▼
19
                        ┌─────────┴─────────────────────────────────┐
20
                        │              Viz Process                   │
21
                        │  • SurfaceManager                          │
22
                        │  • SurfaceAggregator                       │
23
                        │  • Display Compositor                      │
24
                        └───────────────────────────────────────────┘

The public API (LayerTreeHost, Layer) lives on the main thread. Embedders create layers, set properties, and request commits. The internal implementation (LayerTreeHostImpl, LayerImpl) lives on the compositor thread and handles the actual rendering work.

The Three-Tree System

Chromium maintains three layer trees to decouple content updates from display:

A fourth tree, the Recycle Tree, caches the previous pending tree to optimize memory allocation.

Why three trees? Without this separation:

• Commits would block until rasterization completes (frames would drop)
• Partially-rasterized content would be visible (checkerboard artifacts)
• Main thread couldn’t prepare the next frame while the current one renders

The Commit Operation

The Commit synchronizes the main thread tree to the pending tree. This is a blocking operation: the main thread pauses while the compositor copies:

1. Property trees (transform, clip, effect, scroll)
2. Layer metadata (bounds, property tree node IDs)
3. Display lists (paint records for rasterization)

Once commit completes, the main thread resumes and can immediately begin preparing the next frame.

Activation

When tiles in the pending tree are sufficiently rasterized, activation occurs: the pending tree becomes the new active tree. The TileManager controls this timing—activation only proceeds when “NOW” priority tiles (visible in viewport) are ready.

Design rationale: Activation is the safety valve preventing checkerboard. If rasterization falls behind, activation delays rather than showing incomplete content.

Property Trees

Property trees are the modern replacement for hierarchical layer transforms. Instead of walking the entire layer tree to compute a node’s final transform, each layer stores node IDs pointing into separate trees.

The Four Trees

Why Property Trees?

Consider computing the screen-space transform for a deeply nested element:

Legacy approach (layer tree traversal):

1
transform = identity
2
for each ancestor from root to element:
3
    transform = transform × ancestor.localTransform
4
// O(depth) per element, O(depth × layers) total

Property trees approach:

1
transformNode = propertyTrees.transform[element.transformNodeId]
2
transform = transformNode.cachedScreenSpaceTransform
3
// O(1) lookup

Property trees cache computed values at each node. When a transform changes, only affected nodes recompute—not the entire tree. This makes updates O(interesting nodes) instead of O(total layers).

Real-World Impact

A complex page with 1000+ layers (data visualization, infinite scroll) would see catastrophic commit times with layer tree traversal. Property trees keep commit times bounded regardless of layer count—critical for maintaining 60fps.

Compositor Frames

The compositor thread produces CompositorFrames, the data structure that travels to Viz for display. A frame is not a bitmap—it’s a structured description of what to draw.

Frame Structure

1
CompositorFrame
2
├── metadata
3
│   ├── device_scale_factor
4
│   ├── frame_token (for timing)
5
│   └── begin_frame_ack
6
├── RenderPass[] (from back to front)
7
│   └── RenderPass
8
│       ├── id
9
│       ├── output_rect
10
│       ├── damage_rect
11
│       └── DrawQuad[] (drawing primitives)
12
└── resource_list (texture references)

Draw Quads

Draw quads are the atomic drawing primitives:

Each quad carries geometry (transform, destination rect, clip), material properties (texture ID, blend mode), and layer information for z-ordering.

Render Passes

When content requires intermediate textures, multiple render passes are used:

Each additional render pass adds GPU overhead (texture allocation, state changes, draw calls). This is why filter and mix-blend-mode are more expensive than transform and opacity.

Compositor Thread Responsibilities

The compositor thread (LayerTreeHostImpl) handles four critical functions that must remain responsive regardless of main thread state:

1. Input Routing

Scroll and touch events are intercepted before reaching the main thread. The compositor implements InputHandler, allowing it to:

• Apply scroll offsets immediately to the active tree’s property trees
• Handle pinch-zoom by modifying viewport scale
• Route events to the main thread only when necessary (event listeners, non-composited scrollers)

Design rationale: If scroll events went to the main thread first, a blocked main thread would freeze scrolling. By routing input through the compositor, scrolling remains responsive during heavy JavaScript execution.

2. Compositor-Driven Animations

Animations targeting transform, opacity, or filter can run entirely on the compositor thread:

1
/* Compositor-driven: runs on compositor thread */
2
.smooth {
3
  transition:
4
    transform 0.3s,
5
    opacity 0.3s;
6
}
7

8
/* Main-thread required: triggers layout */
9
.janky {
10
  transition:
11
    left 0.3s,
12
    width 0.3s;
13
}

The animation system works by:

1. Main thread creates animation, marks element for promotion
2. Animation metadata copies to compositor during commit
3. Compositor thread ticks animation each frame, updating property tree values
4. GPU re-composites existing textures with new transform/opacity

No re-layout, no re-paint, no re-raster—the textures already exist.

3. Tile Management

The TileManager orchestrates rasterization across worker threads:

Scroll velocity affects binning—fast scrolls expand the “SOON” radius to pre-rasterize more content ahead of the scroll direction.

4. Frame Scheduling

The Scheduler coordinates the rendering pipeline, managing:

• BeginFrame signals from Viz (VSync-aligned)
• BeginMainFrame requests to the main thread
• Activation timing based on tile readiness
• Frame submission deadlines

What Stays Responsive During Main Thread Blocks

The compositor thread handles these operations independently, meaning they continue during heavy JavaScript execution:

2 collapsed lines
1
// Example: 3-second main thread block
2
button.addEventListener("click", () => {
3
  const start = Date.now()
4
  while (Date.now() - start < 3000) {} // Busy loop
5
  console.log("Done!")
6
})

Compositor-handled (still works):

Main-thread-dependent (blocked):

Compositor-Only vs Main-Thread Animations

1
/* ✅ Compositor-only: runs during JS execution */
2
.smooth-spinner {
3
  animation: spin 1s linear infinite;
4
}
5
@keyframes spin {
6
  to {
7
    transform: rotate(360deg);
8
  }
9
}
10

11
/* ❌ Main-thread required: freezes during JS execution */
12
.janky-spinner {
13
  animation: slide 1s linear infinite;
14
}
15
@keyframes slide {
16
  to {
17
    margin-left: 100px;
18
  } /* Layout property */
19
}

The transform animation updates a property tree node value—the compositor applies it to cached GPU textures. The margin-left animation requires layout recalculation, which only the main thread can perform.

Compositor-to-Viz Communication

The compositor thread doesn’t draw pixels directly—it produces CompositorFrame objects that travel to the Viz process (GPU process) for display.

The Frame Sink Interface

Each compositor has a CompositorFrameSink connection to Viz:

1
Renderer Process                           Viz Process
2
────────────────                           ───────────
3
CompositorThread                           SurfaceManager
4
      │                                          │
5
      │ SubmitCompositorFrame(frame)             │
6
      ├─────────────────────────────────────────▶│
7
      │                                          │
8
      │ DidReceiveCompositorFrameAck()           │
9
      │◀─────────────────────────────────────────┤
10
      │                                          │
11
      │ BeginFrame(args)                         │
12
      │◀─────────────────────────────────────────┤

Frame submission flow:

1. Compositor builds CompositorFrame (draw quads, render passes, resource references)
2. Frame submitted via CompositorFrameSink::SubmitCompositorFrame()
3. Viz acknowledges receipt, allowing compositor to recycle resources
4. Viz sends BeginFrame signals (VSync-aligned) to pace frame production

Surface Aggregation

A web page often involves multiple renderer processes (cross-origin iframes), plus the browser UI. Viz aggregates all their frames:

1
Browser UI Frame ────┐
2
Main Page Frame ─────┼──▶ Surface Aggregator ──▶ Aggregated Frame ──▶ Display
3
iframe A Frame ──────┤
4
iframe B Frame ──────┘

The SurfaceAggregator walks SurfaceDrawQuad references recursively, merging frames from all sources. If an iframe’s frame hasn’t arrived, Viz uses the previous frame or a solid color—preventing one slow process from stalling the entire page.

Why Viz Lives in a Separate Process

Security: Renderer processes are sandboxed and cannot access GPU APIs directly. All GPU commands go through Viz.

Stability: GPU driver crashes terminate only the Viz process; renderers survive and reconnect. Users see a brief flash rather than losing their tabs.

Resource management: Viz controls GPU memory allocation across all tabs, preventing any single page from consuming all VRAM (Video Random Access Memory).

Performance Optimization Patterns

Promote Wisely

Layer promotion enables compositor-driven animations but costs memory:

1
/* Explicit promotion hint */
2
.will-animate {
3
  will-change: transform;
4
}
5

6
/* Implicit promotion (has side effects) */
7
.promoted {
8
  transform: translateZ(0); /* Forces own layer */
9
}

Memory cost: Each layer consumes width × height × 4 bytes (RGBA) of GPU memory. A 1920×1080 layer = ~8MB. Mobile devices with shared GPU memory exhaust resources quickly.

When to promote:

• Elements with transform/opacity animations
• Fixed/sticky positioned elements (scroll independently)
• Content with hardware video or WebGL

When NOT to promote:

• Static content (wastes memory)
• Thousands of small elements (layer explosion)
• Content that changes frequently (re-rasterization costs)

Compositor-Only Animations

For 60fps animations, stick to properties the compositor can handle without main thread involvement:

Avoid Forced Synchronous Layout

Reading layout properties after writes forces the browser to synchronously recalculate:

1
// ❌ Forces layout thrashing
2
elements.forEach((el) => {
3
  el.style.width = `${el.offsetWidth + 10}px` // Read triggers sync layout
4
})
5

6
// ✅ Batch reads, then writes
7
const widths = elements.map((el) => el.offsetWidth) // All reads
8
elements.forEach((el, i) => {
9
  el.style.width = `${widths[i] + 10}px` // All writes
10
})

Layout thrashing on the main thread delays commits, which delays frame production.

Failure Modes and Debugging

Checkerboarding

When scrolling reveals tiles that haven’t been rasterized, users see placeholder rectangles (historically a checkerboard pattern, now typically solid colors).

Causes:

• Scroll velocity exceeds rasterization throughput
• Memory pressure evicts pre-rasterized tiles
• Complex content (heavy SVG, many layers) slows rasterization

Debugging: Chrome DevTools → Performance → check for “Rasterize Paint” entries extending beyond frame budgets. The “Layers” panel shows which elements are promoted and their memory consumption.

Layer Explosion

When too many elements are promoted, memory exhausts and performance degrades.

Symptoms:

• High GPU memory usage in Task Manager
• Compositor falls back to software raster
• Animations stutter despite being transform/opacity only

Debugging: DevTools → Layers panel → sort by memory. Look for unexpected promotions from overlap (elements stacking above promoted content force-promote).

Commit Jank

Long commit times steal from the frame budget.

Causes:

• Thousands of layers (each must sync metadata)
• Complex property trees (deep nesting)
• Large display lists (many paint operations)

Debugging: DevTools → Performance → look for long “Commit” entries. The “Summary” tab shows time breakdown.

Conclusion

Compositing is Chromium’s architectural answer to a fundamental constraint: the main thread cannot execute JavaScript and produce visual updates simultaneously. By delegating frame assembly to a dedicated compositor thread with its own layer trees and property trees, the browser maintains responsive scrolling and animations regardless of main thread load.

The key insights for optimization:

1. Promote judiciously: Layer promotion enables compositor-driven animations but costs GPU memory
2. Animate compositor-only properties: transform and opacity skip the entire main-thread pipeline
3. Understand the boundaries: Knowing what the compositor can and cannot do prevents performance surprises
4. Respect the frame budget: Commit, rasterization, and Viz aggregation all compete for the 16ms window

The three-tree architecture (main → pending → active), property tree design, and one-directional dependency (main → compositor, never reverse) are the foundations enabling 60fps+ rendering on complex, multi-process web applications.

Appendix

Prerequisites

• Rendering Pipeline Overview: The end-to-end journey from HTML to pixels
• Paint Stage: How display lists are recorded
• Rasterization: How display lists become GPU textures
• Commit Stage: The synchronization point between threads

Terminology

Summary

• cc (Chrome Compositor) runs on a dedicated thread, enabling responsive scrolling and animations during main thread blocks
• Three-tree architecture (main → pending → active) decouples content updates from display
• Property trees (transform, clip, effect, scroll) provide O(1) lookups instead of O(depth) traversals
• Compositor frames contain draw quads and render passes—abstract descriptions, not bitmaps
• Viz process aggregates frames from all renderer processes and browser UI into a single display output
• Compositor-only properties (transform, opacity) animate without main thread involvement
• One-directional dependency: main thread can block on compositor, but compositor never blocks on main thread

References

• Chromium Design Docs: How cc Works — chromium.googlesource.com

  “The scheduler triggers BeginMainFrame, Blink applies updates, then ProxyImpl copies data to compositor thread structures while temporarily blocking the main thread.”

• Chromium Design Docs: Compositor Thread Architecture — chromium.org

  “This architecture allows us to snapshot a version of the page and allow the user to scroll and see animations directly even when the main thread is blocked.”

• Chrome Developers: RenderingNG Architecture — developer.chrome.com
• Chrome Developers: RenderingNG Data Structures — developer.chrome.com

  “Every web document has four separate property trees: transform, clip, effect, and scroll.”

• Chromium: Life of a Frame — chromium.googlesource.com
• Chromium: Viz Architecture — chromium.googlesource.com
• W3C: CSS Compositing and Blending Level 1 — w3.org
• web.dev: Stick to Compositor-Only Properties — web.dev