Blink286

The text provides an extensive overview of the graph-structured data structures used within Blink, Chromium's rendering engine, detailing how web content is processed from initial input to final display. The core of the pipeline relies on sequential graph transformations, beginning with the DOM tree (representing the document structure), which is used to build the Layout Tree (representing visual formatting and geometry). Modern Blink transitions this into the Immutable Fragment Tree, which is key for painting and hit-testing. The subsequent stage involves the Paint Artifact, composed of a display list and four parallel Property Trees (Transform, Clip, Effect, and Scroll), which manage visual state hierarchies. Finally, these artifacts inform the construction of the Compositing Layer Tree on both the main and compositor threads, enabling efficient rendering and animation. Throughout all these stages, the document emphasizes various traversal concepts—such as pre-order, post-order, and finding the common ancestor—that are fundamental to Blink's algorithms for layout, style calculation, and drawing.

bridges Blink property trees → cc property trees.

Given Blink’s Transform/Clip/Effect/Scroll nodes (from paint property trees), this class creates/updates the cc counterparts (cc::TransformNode, cc::ClipNode, cc::EffectNode, cc::ScrollNode) and associates them with the layers PaintArtifactCompositor builds. This is the last Blink stop before cc consumes the state. (cr-rev.appspot.com)

Representative responsibilities

• Map Blink TransformPaintPropertyNode/Clip.../Effect.../Scroll... into cc nodes with stable IDs;

Update viewport related properties (inner/outer viewport transform/clip) on the cc side. (Chromium Git Repositories)

turns chunks into compositor layers & updates cc property trees.

 Consumes the new PaintArtifact and does the layerization and property‑tree updates required for compositor draw. It supports fast paths when only values changed (e.g., opacity) or when a scroll only induces raster invalidation, avoiding full rebuilds. It owns a subtree of cc layers corresponding to the artifact. (Chromium Git Repositories)

Key fields

• scoped_refptr root_layer_ — root of the Blink‑owned layer subtree.

• UpdateType needs_update_ — kRepaint vs kFull (or scroll fast path).

• Caches/maps for synthesized mask clips and scroll translations seen while layerizing. (Chromium Git Repositories)

Most important methods

• bool TryFastPathUpdate(const PaintArtifact&) — take a cheap path (no topology change). (Chromium Git Repositories)

• void Update(const PaintArtifact&, const ViewportProperties&, const StackScrollTranslationVector&, Vector>) — full reconciliation to layers + cc property trees. (Chromium Git Repositories)

• “Direct update” helpers like DirectlyUpdateCompositedOpacityValue(...), DirectlyUpdateScrollOffsetTransform(...) — skip rebuilds for common animations/scrolling. (Chromium Git Repositories)

Hands off to: PropertyTreeManager (internally) to mirror Blink property nodes to cc trees, ready for commit to the compositor thread.

grouping and content.

• PaintChunk: groups sequential display items that share the same property‑tree state and cull/visibility; it’s the unit we layerize and invalidate.

• DisplayItemList: the recorded Skia/paint operations (text, images, paths, etc.). This split lets us reason about “where/how to draw” (chunk) vs. “what to draw” (items). (Chromium Git Repositories)

Hands off to: PaintArtifactCompositor for compositing decisions, then PropertyTreeManager to mirror trees into cc.

the immutable “what to draw” package for this frame.

A PaintArtifact is the product of Blink painting: a DisplayItemList plus an ordered vector of PaintChunks. It is immutable post‑creation and designed for reuse (granular caching at item/chunk level) across frames. (Chromium Git Repositories)

Notable API/fields

• const DisplayItemList& GetDisplayItemList() const;

• const PaintChunks& GetPaintChunks() const; — the input that compositing consumes. (Chromium Git Repositories)

Hands off to: PaintArtifactCompositor.

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.