How Chromium's Zero-Copy Rasterization Works

This article explains the mechanics of Zero-Copy rasterization in the Chromium web browser. It details how the browser eliminates redundant data transfers by utilizing specialized OS-level memory buffers, allowing the CPU to write pixel data directly into a shared system memory space that the GPU can immediately read and display on the screen.

The Traditional Rasterization Bottleneck

To display a webpage, Chromium breaks the page down into smaller squares called tiles. The process of converting webpage code (HTML, CSS) into actual pixels inside these tiles is called rasterization.

In standard "One-Copy" rasterization, the CPU rasterizes the tile into regular system memory (RAM). Then, that pixel data must be copied over to the GPU’s dedicated memory (VRAM) so the GPU can composite the tiles onto the screen. This copying step consumes memory bandwidth, increases latency, and drains battery life.

The Zero-Copy Solution

Zero-Copy rasterization eliminates this transfer step entirely. It achieves this primarily on devices with Unified Memory Architectures (where the CPU and GPU share the same physical RAM, common in mobile devices and integrated graphics) through the following process:

1. Allocation of GpuMemoryBuffers Instead of using standard system memory, Chromium’s GPU process allocates a special block of shared system memory called a GpuMemoryBuffer. Chromium relies on native operating system APIs to create these buffers, such as IOSurface on macOS, SurfaceTexture/AHardwareBuffer on Android, DMABUF on Linux, and DXGI on Windows.

2. Memory Mapping Once the GpuMemoryBuffer is created, it is mapped into the virtual address space of the Chromium Renderer process. This gives the CPU direct access to the exact same physical memory location that the GPU is aware of.

3. Direct CPU Writing The Renderer process uses its raster worker threads (powered by the Skia graphics library) to decode images and paint the webpage's pixel data. Because the shared buffer is mapped to the Renderer, the CPU writes the rasterized tile data directly into the GpuMemoryBuffer in system memory.

4. Synchronization and Texture Binding When the CPU finishes drawing a tile, it unlocks the buffer and sends a lightweight signal (a sync token) to the GPU process indicating the data is ready. No pixel data is moved during this step. The GPU process then binds this shared memory buffer directly as a hardware texture.

5. Direct GPU Reading When it is time to draw the final webpage frame, the GPU compositor reads the pixel data directly from the bound GpuMemoryBuffer in the shared system memory. Because the OS-level buffer is natively understood by the graphics hardware, the GPU treats this shared system memory as if it were its own local memory, reading the tiles and rendering the final image to the display with zero intermediate copies.