Understanding Chrome's Multi‑Process Architecture and Rendering Pipeline

Background

As the number of danmaku (bullet comments) and animated effects on videos grows, ensuring smooth display becomes a performance challenge. Understanding the browser's low‑level rendering principles is essential for minimizing resource consumption.

Goal

This article explains how Chrome renders pages on the screen and identifies optimization points for smoother animations.

1. Chrome Multi‑Process Model

1.1 Main Processes

Chrome separates work into several processes:

Browser : Handles UI elements (address bar, bookmarks, navigation) and invisible tasks such as network requests and file I/O.

Renderer : One per tab, responsible for HTML parsing and JavaScript execution.

Plugin : Runs each extension in its own process to isolate crashes.

GPU : Dedicated to 3D CSS effects and UI compositing.

Additional processes include Extension and Utility processes, viewable via the Chrome Task Manager.

1.2 Advantages and Disadvantages

Benefits

Fault isolation: a crash in one tab does not affect others.

Security sandbox: each process has limited system privileges.

Drawbacks

Higher memory usage due to separate address spaces.

Improvements

Process limit: tabs loading the same site may share a renderer.

Dynamic process allocation based on hardware capability.

2. From URL Input to Page Display

2.1 Tasks Performed by the Browser Process

Step 1 – Input handling : UI thread determines whether the input is a search query or a URL.

Step 2 – Navigation start : If it is a URL, the UI thread triggers a network request (DNS, TCP handshake, etc.) and shows a loading indicator. It also asks the browser process to launch a renderer.

Step 3 – Response reading : Handles redirects, MIME type detection, and possible download of compressed files.

Step 4 – Finding a renderer : After security checks, the browser selects an appropriate renderer process.

Step 5 – Navigation commit : Browser sends an IPC message to the renderer to commit navigation; the navigation bar updates and a session history entry is created.

Step 6 – Rendering continues : The renderer receives HTML, parses resources, and notifies the browser when all resources are loaded, removing the loading indicator.

3. Rendering Process and GPU Process Tasks

3.1 Role of the Renderer Process

The renderer converts HTML, CSS, and JavaScript into interactive web content.

3.2 Main Thread Tasks

The main thread parses HTML into tokens, builds the DOM tree, parses CSS into a CSS rule tree, and then creates a layout tree by combining DOM and CSS rules.

3.2.1 After DOM creation, four trees are generated:

Layout tree (visible nodes with geometry)

Paint tree (drawing commands)

Graphics (compositing) tree

Render layers (compositing layers)

3.2.2 Paint Phase

The layout tree is traversed to generate paint records (e.g., "draw background then text").

3.2.3 Compositing Phase

Paint records are turned into graphic layers. Only elements that satisfy certain conditions (3D transform, video, accelerated canvas, etc.) become separate compositing layers.

3.3 Compositing Thread Tasks

Tile division: split layers into 256×256 or 512×512 tiles.

Rasterization: convert paint records of each tile into bitmaps stored in GPU memory.

Paint quads: describe tile geometry and position.

Compose frame: assemble all paint quads into a frame.

3.4 GPU Process

The compositing thread serializes commands into shared memory; the GPU process reads them, executes the graphics calls, writes the result to the frame buffer, and the display controller presents frames synchronized with VSync.

4. Danmaku (Bullet Comment) Implementation

A list maintains all active comments. Each frame, the next comments are fetched. If a cached DOM node exists, it is reused; otherwise a new node is created. The comment’s width and height determine its track, then a translation animation moves it across the screen. Once the comment leaves the viewport, its node is cached for future reuse, reducing DOM creation overhead.

Conclusion

The article demonstrates how Chrome’s multi‑process architecture, rendering pipeline, and GPU acceleration work together, providing insights for building high‑performance web animations such as danmaku.