Blink286

Layout takes the styled DOM and produces a fragment tree of positioned boxes. In modern Blink this is LayoutNG; the core artifact is NGPhysicalFragment, which stores geometry and is used downstream for pre‑paint (e.g., to compute clips, overflow, and hit regions). (Chromium Git Repositories)

Representative APIs
Geometry/ink overflow helpers and accessors on NGPhysicalFragment expose the post‑layout shape of the page that pre‑paint/paint will consume. (See header for geometry utilities.) (Chromium Git Repositories)

Hands off to: PrePaintTreeWalk (to build/refresh property trees and invalidations over the laid‑out fragments).

style invalidation & resolution (recalc). 
Given DOM/style changes since the last frame, StyleEngine computes updated ComputedStyles, manages active stylesheets/media query state, and marks the right subtrees dirty for style/layout. This sets up accurate inputs to layout. (Chromium Git Repositories)

Key fields

* StyleResolver* resolver_ — the style resolver used to compute ComputedStyles; created lazily. (Chromium Git Repositories)

* PendingInvalidations pending_invalidations_ — tracks nodes needing restyle due to stylesheet/DOM/class/attribute changes. (Chromium Git Repositories)

Most important methods (and how they push pixels forward)

* StyleResolver& EnsureResolver() — makes sure a resolver is ready before recalc. (Chromium Git Repositories)

* void UpdateActiveStyle() — updates active sheets/media‑query driven state before resolving. (Chromium Git Repositories)

* void RecalcStyle(StyleRecalcChange) — does the actual style recalc walk, marking what changed for layout/paint. (Chromium Git Repositories)

* A large set of ...ChangedForElement(...) and ScheduleInvalidations...(...) helpers — turn DOM/sheet churn into precise invalidations (minimizing layout/paint cost). (Chromium Git Repositories)

Hands off to: Layout (LayoutNG) with up‑to‑date ComputedStyle.

states that gate phases.

The document owns the DOM and keeps a DocumentLifecycle state machine that ensures we do things in phase order (style before layout, pre‑paint before paint, etc.). Lifecycle transitions are what UpdateLifecycle(...) advances each frame. (source.chromium.org)

Why it matters

The lifecycle enumerates phases (e.g., style recalc, pre‑paint, paint), and code uses those to assert correct ordering—critical for correctness and avoiding dirty‑state bugs during a frame. (source.chromium.org)

Hands off to: StyleEngine for style work, then on to layout and paint.

orchestrates style → layout → pre‑paint/paint for a frame. This is the workhorse that actually runs lifecycle phases. On a frame tick from WebFrameWidgetImpl, it goes through style recalc, layout (LayoutNG), pre‑paint (build property trees, invalidation), paint (record display list), and then kicks compositing with the new artifact. It also wires in PaintArtifactCompositor and traversal helpers like PrePaintTreeWalk. (Chromium Git Repositories)

Most important collaborations

* Includes/uses: PrePaintTreeWalk, PaintArtifactCompositor, GraphicsContext, PaintController. These glue together pre‑paint traversal, display list recording, and handoff to compositing. (Chromium Git Repositories)

Hands off to: Document (style), LayoutNG fragments, PrePaintTreeWalk, PaintController, then PaintArtifactCompositor.

the document host and local‑root boundary.
The local frame owns the Document and its LocalFrameView. The local root frame coordinates lifecycle for its subtree (including OOPIF boundaries handled later on the viz side). (Chromium Git Repositories)

Key methods/fields

* bool IsLocalRoot() const; LocalFrame& LocalFrameRoot() const; — define the subtree that this frame is responsible for during lifecycle (important for scoping style/layout/paint). (Chromium Git Repositories)

* Accessors into the view and document (used throughout the lifecycle calls). (Chromium Git Repositories)

Hands off to: LocalFrameView (view/lifecycle engine) and Document.

the page container and animation clock keeper. Page holds frame trees and the PageAnimator that services script‑driven animations on each tick. It’s the top‑level context for the document/view that WebFrameWidgetImpl coordinates with. You see it pulled into the document and frame code paths whenever lifecycle‑wide actions are taken. (Chromium Git Repositories)

Important relationships

* Owns PageAnimator used when Blink services CSS/Web Animations during lifecycle updates. (Chromium Git Repositories)

Hands off to: LocalFrame/LocalFrameView for concrete style/layout/paint work.

renderer‑main entry to Blink’s lifecycle.

This is where a compositor BeginFrame (coming in via content/public and mojo plumbing) first turns into Blink work on the renderer main thread. It receives the frame tick, decides what lifecycle phases to run (e.g. style/layout/paint), and pushes the work into the local root’s LocalFrameView. (Chromium Git Repositories)

Key fields (why they matter)

* scoped_refptr root_layer_ — holds the Blink‑owned root cc layer for this widget’s subtree; exists so Blink can update properties before the commit boundary. (Chromium Git Repositories)

* std::unique_ptr animation_host_ — lets main‑thread animations be driven and ticked in sync with lifecycle updates. (Chromium Git Repositories)

* std::unique_ptr layer_tree_view_ — the view side of the compositor connection that WebFrameWidgetImpl closes/tears down when the widget goes away. (Chromium Git Repositories)

Most important methods (how they advance the pixel)

* void BeginMainFrame(base::TimeTicks last_frame_time) — entry point for a new main‑thread frame; schedules lifecycle phase execution in Blink. (Chromium Git Repositories)

* void UpdateLifecycle(WebLifecycleUpdate requested_update, DocumentUpdateReason reason) — runs the Blink lifecycle (style → layout → pre‑paint/paint) as needed for this frame. (Chromium Git Repositories)

* void RecordEndOfFrameMetrics(base::TimeTicks frame_begin_time) — stamps timing for UMA/UKM; not directly pixel‑producing but tied to the same lifecycle boundary. (Chromium Git Repositories)

Hands off to: LocalFrameView of the local root to perform style/layout/paint.

The collection of sources provides a detailed technical analysis of the ComputedStyle object within Blink, the rendering engine for Chromium. The primary source, an in-depth analysis document, explains how ComputedStyle and its generated storage class, BaseComputedStyle, represent the final, resolved CSS values for an element following the RenderingNG pipeline update. The design emphasizes immutability after style resolution, efficient copy-on-write semantics using grouped data fields to save memory, and generated code to handle the numerous CSS properties and comparison logic. These structures are crucial for the rendering process, informing subsequent stages like layout and paint by providing comparison functions (StyleDifference) that determine necessary updates.

The source material, primarily an excerpt from a 2025 technical report, provides an in-depth analysis of the LayerContext abstraction within the Chromium RenderingNG pipeline, specifically when the browser's compositor and the GPU's display compositor run in separate processes using the "Trees In Viz" configuration. LayerContext acts as the crucial boundary object, with the VizLayerContext implementation on the client side responsible for serializing incremental updates—including property tree changes, layer properties, and scroll offsets—into Mojo messages. Conversely, the LayerContextImpl on the server (GPU) side receives these messages, applies the updates to its local LayerTreeHostImpl, and then draws and submits the final frame. This mechanism is central to ensuring efficient synchronization of scroll deltas and other state changes across process boundaries without requiring a full commit for every update.

(Make it over 20000 words)

source text provides an extremely detailed, technical overview of the blink::PaintPropertyTreeBuilder class in Chromium, which is responsible for building the rendering pipeline's four synchronized yet independent property trees (transform, clip, effect, and scroll). The document describes this process as a "surgical tour of dragons" because of the combinatorial complexity required to reconcile all CSS, SVG, and layout features (like sticky positioning, fragmentation, and view transitions) across these four topologies during the PrePaint phase. The explanation walks through the structure of the class, detailing the purpose of various helper contexts, the critical decision gates that determine which nodes are built, and complex edge cases like subpixel accumulation, isolation nodes, and fast paths for direct compositor updates. Ultimately, the class ensures that the Chromium rendering engine can correctly express complex relationships—such as effects and transforms—that cannot be modeled by the single DOM tree, thereby enabling features like fast partial updates and fixing rendering paradoxes.