How Out-of-Process Rasterization Improved Chromium
Out-of-Process Rasterization (OOP-R) is a major architectural upgrade in the Chromium web browser that moved the task of converting web content into pixels from the renderer process to the GPU process. This article explains the mechanics of OOP-R, how it replaced legacy rendering methods, and the specific ways it enhanced both graphics security and browser performance in Chromium.
What is Rasterization?
Before a web page can be displayed on a screen, the browser must translate the page's HTML, CSS, and JavaScript into actual pixels. This translation is called rasterization. Chromium uses an open-source 2D graphics library called Skia to handle this task, leveraging the computer's Graphics Processing Unit (GPU) to draw the pixels quickly and efficiently.
The Shift to Out-of-Process Rasterization
To understand OOP-R, it helps to look at how Chromium previously handled graphics. Chromium uses a multi-process architecture to keep tabs isolated and secure.
In the legacy system (known as In-Process GPU Rasterization), the Renderer Process used the Skia library to convert web content into low-level OpenGL commands. Because the Renderer Process is sandboxed and cannot talk to the GPU hardware directly for security reasons, it had to send these OpenGL commands across an Inter-Process Communication (IPC) channel—called the command buffer—to the GPU Process, which then executed them.
Out-of-Process Rasterization changed this workflow by moving the Skia library out of the Renderer Process and directly into the GPU Process. With OOP-R, the Renderer Process simply records high-level drawing instructions, known as "PaintOps," and sends them to the GPU Process. The GPU Process then uses Skia to rasterize those instructions directly on the graphics hardware.
How OOP-R Improved Security
The GPU Process has direct access to system hardware, making it a prime target for malicious attacks. OOP-R significantly hardened Chromium's security in the following ways:
- Reduced Attack Surface: In the legacy system, the GPU Process had to validate thousands of complex, low-level OpenGL commands coming from the untrusted Renderer Process. Any bug in this validation layer could allow an attacker to take over the GPU Process. OOP-R replaced these complex commands with a much smaller, simpler set of high-level PaintOps, which are far easier to validate and secure.
- Elimination of the GL Command Buffer for Raster: By removing the need for the Renderer Process to generate OpenGL commands for 2D rendering, Chromium eliminated a massive amount of complex code that was historically prone to security vulnerabilities.
- Stricter Sandboxing: Moving graphics driver interactions entirely out of the reach of the Renderer Process allowed Chromium engineers to lock down the renderer sandbox even further.
How OOP-R Improved Performance
Beyond security, moving rasterization to the GPU Process removed several performance bottlenecks:
- Lower IPC Overhead: Sending high-level PaintOps between processes requires transferring much less data than sending thousands of individual low-level OpenGL commands. This reduction in data transfer freed up CPU resources and reduced latency.
- Removal of Command Buffer Translation: The legacy command buffer had to serialize OpenGL commands in the renderer, send them over IPC, and deserialize them in the GPU process. OOP-R bypasses this entire translation layer, allowing Skia to talk directly to the GPU drivers.
- Modern Graphics API Support: The legacy command buffer was strictly built around OpenGL. To use modern, high-performance graphics APIs like Vulkan, Metal, or Direct3D, Chromium previously had to translate OpenGL commands into these newer APIs, which hurt performance. Because Skia now lives in the GPU process with OOP-R, it can use Vulkan and Metal natively, unlocking faster frame rates and lower power consumption.
- Better GPU Resource Management: With the GPU Process having full visibility and control over the rasterization pipeline, it can manage textures, memory, and scheduling much more efficiently than when it was blindly executing commands from multiple renderer processes.