Critical Rendering Path: Layerize

The Layerize stage converts paint chunks into composited layers (cc::Layer objects), determining how display items should be grouped for independent rasterization and animation. This process happens after Paint produces the paint artifact and before Rasterization converts those layers into GPU textures.

Abstract

Layerization is the merging and grouping phase that converts paint output into compositor-ready structures.

The Core Model:

1
Paint Chunks → PendingLayers → cc::Layers + cc::PropertyTrees
2
     ↑              ↑                ↑
3
     │              │                │
4
  input        intermediate      output
5
(per PropertyTreeState)  (merged groups)  (compositor-ready)

Key decisions:

Why separate from Paint? CompositeAfterPaint (M94) moved layerization after paint because:

1. Paint produces immutable output—no circular dependencies
2. Runtime factors (memory pressure, overlap analysis) inform layer decisions
3. The main thread completes paint recording before layerization begins

Why not on compositor thread? Layerization examines the paint artifact, which lives on the main thread. The compositor thread receives the finalized layer list and property trees during Commit.

The Layerization Algorithm

The PaintArtifactCompositor implements layerization via LayerizeGroup(), converting paint chunks into compositor layers through a two-phase process.

Phase 1: Create PendingLayers

Each paint chunk initially becomes a PendingLayer—an intermediate representation that may later merge with others.

1
Paint Chunk A (transform_id=1, clip_id=1, effect_id=1) → PendingLayer A
2
Paint Chunk B (transform_id=1, clip_id=1, effect_id=1) → PendingLayer B
3
Paint Chunk C (transform_id=2, clip_id=1, effect_id=1) → PendingLayer C

What PendingLayer holds:

Phase 2: Merge PendingLayers

The algorithm attempts to combine PendingLayers to reduce layer count. Merging succeeds when:

1. Compatible PropertyTreeState: Adjacent chunks share the same transform, clip, and effect ancestors
2. No overlap conflicts: The chunk doesn’t interleave with content already assigned to incompatible layers
3. Within sparsity tolerance: Combined bounds don’t waste excessive GPU memory (kMergeSparsityAreaTolerance)

When PropertyTreeStates differ but merging is still beneficial, the algorithm flattens the difference by emitting paired display items that adjust the chunk’s state to match the target layer.

Merge Prevention: Direct Compositing Reasons

Certain property nodes carry direct compositing reasons that prevent merging:

Elements with direct compositing reasons become their own layers regardless of merging opportunities.

Merge Prevention: Overlap Testing

When a paint chunk overlaps content already assigned to an incompatible layer (different z-order, different PropertyTreeState), it cannot merge with that layer. This overlap testing maintains correct visual ordering.

Example of overlap forcing layer creation:

1
Layer A: Element with will-change: transform (z-index: 1)
2
Layer B: ???
3

4
Paint Chunk X (z-index: 2, overlaps A)
5
  → Cannot merge with A (different z-order)
6
  → Cannot merge with any earlier layer (would violate paint order)
7
  → Must become new Layer B

This cascade can cause layer explosion: one promoted element forces neighbors to promote, which forces their neighbors, etc. The compositor mitigates this through layer squashing—merging multiple overlapping elements into a single layer when they share the same compositing context.

Algorithm Complexity

“In the worst case, this algorithm has an O(n²) running time, where n is the number of PaintChunks.” — Chromium Blink Compositing README

The quadratic worst case occurs when every chunk must be checked against every preceding layer for overlap. Typical pages have far fewer problematic interactions, making practical complexity closer to O(n × average_layer_count).

From PendingLayers to cc::Layers

Once the PendingLayer list is finalized, PaintChunksToCcLayer::Convert() creates actual compositor layers.

Layer Types Created

Property Tree Conversion

Blink property tree nodes referenced by paint chunks are converted to equivalent cc::PropertyTree nodes:

1
Blink TransformNode → cc::TransformTree node
2
Blink ClipNode → cc::ClipTree node
3
Blink EffectNode → cc::EffectTree node
4
Blink ScrollNode → cc::ScrollTree node

Each cc::Layer stores node IDs pointing into these trees, not hierarchical transform chains. This enables O(1) property lookups during compositing.

Non-composited nodes (those merged into layers with different PropertyTreeStates) become meta display items within the layer’s paint record, effectively baking the transform/clip/effect into the recorded drawing commands.

Hit-Test Opaqueness Accumulation

During layerization, hit-test opaqueness propagates from paint chunks to layers:

1
Paint Chunk: hit_test_opaqueness_ = OPAQUE
2
  ↓ accumulate
3
cc::Layer: hit_test_opaqueness = OPAQUE (can be hit-tested on compositor thread)

This enables the compositor to handle hit testing for opaque regions without consulting the main thread—critical for responsive input during JavaScript execution.

Layerization and Memory Trade-offs

Layer decisions directly impact GPU memory consumption and rasterization cost.

Memory Cost Per Layer

Each composited layer consumes GPU memory proportional to its pixel area:

Formula: Width × Height × 4 bytes (RGBA)

Mobile devices with shared GPU memory (2-4 GB total RAM) exhaust resources quickly. Aggressive layerization can cause:

• Checkerboarding during scroll
• Fallback to software rasterization
• Browser process crashes

The Merge vs. Separate Trade-off

Example: A scrollable list with 100 items:

• Merged approach: One PictureLayer containing all items. Scrolling uses compositor offset; content change re-rasters entire layer.
• Separated approach: 100 PictureLayer objects. Each change re-rasters one layer, but uses 100× the memory.

The algorithm balances these by merging by default but separating content expected to change independently.

Optimization: Avoiding Full Layerization

PaintArtifactCompositor::Update() is expensive. Chromium implements fast paths for common scenarios:

Repaint-Only Updates

When display items change but layerization structure remains stable:

1
UpdateRepaintedLayers():
2
  - Skip LayerizeGroup()
3
  - Update existing cc::Layer display lists in-place
4
  - No layer tree reconstruction

Triggers: Color changes, text updates, background modifications that don’t affect bounds or PropertyTreeState.

Direct Property Updates

Transform or opacity changes that don’t affect layer structure:

1
DirectCompositorUpdate():
2
  - Skip both layerization and display list update
3
  - Modify cc::PropertyTree nodes directly
4
  - Compositor applies new values during compositing

Triggers: transform or opacity animations on already-promoted layers.

Raster-Inducing Scroll

Scroll position changes within a composited scroller:

1
kRasterInducingScroll:
2
  - Minimal update path
3
  - Adjust scroll offset in property trees
4
  - Rasterize newly-visible tiles only

Historical Evolution

Pre-CompositeAfterPaint (Before M94)

Layerization occurred before paint:

1
Style → Layout → Compositing (layerization) → Paint

Problems:

1. Circular dependency: Paint invalidation needed current layer decisions; layer decisions needed paint output
2. Heuristic complexity: 22,000+ lines of C++ to guess which elements needed layers
3. Correctness bugs: Fundamental compositing errors from premature decisions

The codebase relied on DisableCompositingQueryAsserts objects to suppress safety checks—a code smell indicating architectural problems.

CompositeAfterPaint (M94+)

The modern pipeline inverts the order:

1
Style → Layout → Prepaint → Paint → Layerize → Commit → Raster

Benefits:

• Paint produces immutable output before layerization examines it
• Layer decisions based on actual content, not predictions
• Simpler, more correct algorithm
• Enabled Non-Blocking Commit and off-main-thread compositing improvements

Slimming Paint Project (2015-2021)

The broader architectural shift from “tree of cc::Layers” (GraphicsLayer in Blink terminology) to a “global display list” architecture:

• BlinkGenPropertyTrees (M75): Blink generates property trees instead of cc re-generating them
• Paint Chunks: Introduced as intermediate representation for raster invalidation and layerization
• CompositeAfterPaint (M94): Final phase completing the architectural transformation

Debugging Layerization

Chrome DevTools

Layers Panel (More Tools → Layers):

• View compositor layer tree
• See compositing reasons for each layer
• Memory consumption per layer
• Paint counts and slow scroll rects

Performance Panel:

• “Layerize” events in flame chart (rare; usually batched with “Commit”)
• Layer count changes over time
• Correlation with memory pressure

Compositor Debugging Flags

# Enable compositing borders (colored borders around layers)
--show-composited-layer-borders

# Log compositing reasons
--log-compositing-reasons

Common Issues

Conclusion

Layerization is the decision-making phase that transforms paint output into compositor-ready structures. The algorithm balances GPU memory conservation (merge layers) against animation flexibility (separate layers).

Key takeaways:

1. PendingLayers are intermediate: Paint chunks first become PendingLayers, then merge into final cc::Layers
2. Merging is the default: Fewer layers means less GPU memory; separation requires explicit reasons
3. Direct compositing reasons prevent merging: will-change, 3D transforms, compositor animations need isolated layers
4. Overlap forces layer creation: Maintaining z-order correctness can cascade into layer explosion
5. CompositeAfterPaint (M94) moved layerization after paint, eliminating circular dependencies and enabling a cleaner algorithm
6. Fast paths exist: Repaint-only and direct property updates skip full layerization

For production optimization: avoid unnecessary will-change (causes layer promotion), use contain: strict on independent components (limits overlap cascade), and monitor layer count in DevTools to prevent GPU memory exhaustion.

Appendix

Prerequisites

• Paint Stage: Understanding paint chunks and display items
• Commit Stage: How layers transfer to compositor thread
• Rasterization: How layers become GPU textures
• Compositing: How layers assemble into frames

Terminology

Summary

• Layerization converts paint chunks → PendingLayers → cc::Layers
• Algorithm merges by default to conserve GPU memory
• Direct compositing reasons (will-change, 3D transforms, animations) force separate layers
• Overlap testing maintains correct z-ordering but can cause layer explosion
• CompositeAfterPaint (M94) eliminated circular dependencies by moving layerization after paint
• O(n²) worst case complexity; practical performance much better for typical pages
• Fast paths (repaint-only, direct property updates) skip full layerization when possible
• GPU memory is the primary constraint: each layer costs width × height × 4 bytes

References

• Chromium Blink Compositing README — Layerization algorithm and PendingLayer mechanics
• Chromium Platform Paint README — Paint chunks and PaintArtifactCompositor
• Chromium Core Paint README — Paint-to-compositing workflow
• Chromium: How cc Works — Compositor architecture and layer trees
• Chromium: RenderingNG Architecture — Pipeline overview and stage responsibilities
• Chromium: RenderingNG Data Structures — Paint chunks, property trees, composited layers
• Chromium: BlinkNG — CompositeAfterPaint rationale and benefits
• Chromium: GPU Accelerated Compositing — Compositing reasons and layer squashing
• Chromium: Slimming Paint — Historical evolution from GraphicsLayer tree to display list architecture