Chromium Rendering Pipeline Overview

This article provides a comprehensive overview of the Chromium rendering pipeline, explaining how bytecode received from the network is transformed step‑by‑step into pixels displayed on the screen.

It begins with a brief introduction to modern browser architecture and presents two key formulas: Browser = Browser kernel + services and Kernel = Rendering engine + JavaScript engine + others . A table then shows how different browsers map to these components (e.g., Chrome = Chromium + Google services, Edge = Chromium + Microsoft services).

The Chromium process model is described, highlighting the five main process types (Browser, Utility, Viz, Plugin, Render) and their responsibilities, as well as the typical per‑tab process strategy.

The core of the article walks through the 13 stages of the rendering pipeline:

Parsing : Blink parses network bytes into a DOM tree (functions such as blink::HTMLDocumentParser::Append and related stack traces are shown).

Style : The style engine matches CSS rules to DOM nodes, builds a Render Tree, and computes ComputedStyle .

Layout : Geometry (position and size) is calculated, producing a Layout Tree.

Pre‑paint : Property trees are generated for the compositor to avoid redundant raster work.

Paint : Blink creates cc::Layer objects and a cc::DisplayItemList that describe drawing commands.

Commit : Paint results are pushed from the main thread to the compositor thread via PushPropertiesTo .

Compositing : Layers are separated into independent graphics layers for efficient updates.

Tiling : Large layers are split into tiles (e.g., 256×256) for rasterization.

Raster : Tiles are rasterized on a raster thread using various cc::RasterBufferProvider implementations (GPU, software, etc.).

Activate : The pending layer tree is promoted to the active tree.

Draw : Draw quads are generated from the active tree.

Aggregate : The Viz process aggregates compositor frames from multiple processes.

Display : The final frame is sent to the GPU (or software buffer) and presented on screen using double buffering.

Code examples are included, such as an HTML snippet illustrating a multi‑iframe page and a C++ stack trace from the parsing stage, both wrapped in ... tags.

The article concludes with a comparison of synchronous vs. asynchronous rasterization strategies and their impact on memory usage, first‑paint performance, and animation smoothness.