builds the display list + paint chunks and manages caching.

 As painters call into GraphicsContext, they also drive a PaintController which groups drawing into display items and paint chunks (each keyed by the current property‑tree state). It also handles reuse of cached items to avoid repaint when nothing visually changed. Output is an immutable PaintArtifact. (Chromium Git Repositories)

Key fields

• PaintArtifact* new_paint_artifact_ — being built for this frame;

• PaintArtifact* old_paint_artifact_ — previous frame for cache matching;

• PaintChunker paint_chunker_ — forms chunk boundaries based on property state;

• PaintControllerPersistentData* persistent_data_ — holds prior artifact & subsequences. (Chromium Git Repositories)

Most important methods

• UpdateCurrentPaintChunkProperties(const PropertyTreeStateOrAlias&) — starts/updates the current chunk when property state changes. (Chromium Git Repositories)

• template CreateAndAppend(...) — appends a display item (records drawing op + metadata). (Chromium Git Repositories)

• bool UseCachedItemIfPossible(...) — reuses prior items to skip repaints. (Chromium Git Repositories)

• void BeginFrame(const void* frame) / FrameFirstPaint EndFrame(const void* frame) — delimit a painting pass for metrics + cache book‑keeping. (Chromium Git Repositories)

• (Internals also maintain id→index maps to support O(1)/linear cache lookups.) (Chromium Git Repositories)

Hands off to: the PaintArtifact it produces.

immediate drawing API that records to a display list.

 Painters for layout objects use GraphicsContext to “draw”—but in modern Blink those calls get recorded into a display list (PaintRecord) backed by Skia commands. This recording is scoped and batched between BeginRecording(...)/EndRecording(). (Chromium Git Repositories)

Key methods (how display items get their pixels)

• Recording: BeginRecording(const FloatRect&) → sk_sp EndRecording() — wraps a run of drawing commands for later replay. (Chromium Git Repositories)

• Draw ops (representative): DrawRect, DrawImage(...), DrawText(...), BeginLayer/EndLayer — the stuff that becomes Skia ops inside display items. (Chromium Git Repositories)

Important fields

• cc::PaintCanvas* canvas_ (owned by recorder), PaintRecorder paint_recorder_ — actual recording guts;

• float device_scale_factor_, state stacks/flags — needed for correct pixel snapping/appearance. (Chromium Git Repositories)

Hands off to: PaintController, which packages these recorded ops into chunks/items.

 These are the nodes within those four trees. Every piece of painted content (a “paint chunk”) is associated with a tuple of (Transform, Clip, Effect, Scroll) nodes—its PropertyTreeState. This precisely defines where and how to draw it and enables efficient partial updates. (Chromium Git Repositories)

What they carry (high‑value fields)

• Transform: a 4×4 matrix, a 3‑D transform origin, and flags like “flattens” (affects 3D→2D projection). (Chromium Git Repositories)

• Clip: clip rect (possibly rounded), optional clip path, and the associated transform space. (Chromium Git Repositories)

• Effect: opacity, blend mode, filters, masks—i.e., how content is composited into what’s beneath. (Chromium Git Repositories)

• Scroll: the scroll translation (and identity info) that ties content to a scroller. (Chromium Git Repositories)

Change tracking Nodes track change types (PaintPropertyChangeType) so we can choose fast paths (e.g., update value without rebuilding topology). (Chromium Git Repositories)

Hands off to: painting/recording with GraphicsContext + PaintController.

builds/updates paint property trees.

Consumes the layout/fragment data and produces the four paint property trees (Transform, Clip, Effect, Scroll) for the current frame. These trees encode coordinate systems, clipping, visual effects, and scrolling in a way that can be reused across frames and mapped into cc. (Chromium Git Repositories)

Key idea
It decides when nodes change values vs. structure (important for fast paths like “directly update compositor node”), and prepares the property state used to key paint chunks later. (Chromium Git Repositories)

Hands off to: the actual recording of display items with property‑tree state.

cross‑frame pre‑paint traversal.

Runs in the InPrePaint lifecycle phase. Walks the entire layout tree starting at the root LocalFrameView, updating paint invalidation state and computing the context needed by the tree‑building step (e.g., event‑handler flags, fragmentation context, containers for out‑of‑flow). (Chromium Git Repositories)

Key types & fields

* void WalkTree(LocalFrameView& root_frame) — entry to pre‑paint traversal. (Chromium Git Repositories)

* struct PrePaintTreeWalkContext — per‑walk state (e.g., paint_invalidator_context, inside_blocking_touch_event_handler, fragmentation containers). These flags determine whether descendants need updates. (Chromium Git Repositories)

Hands off to: PaintPropertyTreeBuilder and then painting.

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.