Introduction
🥳 Welcome to the Chrome Graphics Book! 🥳
In this book, we're going to go on a whirlwind tour of the architecture of Graphics in Chrome and ChromeOS.
There are several target audiences for this project:
- Engineers interested in understanding or working on graphics in Chrome/ChromeOS
- PMs, TPgMs, PgMs interested in getting a sense of the technical details of our graphics stack
Organization
This document is divided into three major sections:
- Broad Architecture and Big Boxes
A general overview of the high-level architecture of Chrome/ChromeOS. Ideas, not code. - Foundational Concepts and Code
Explanations of and pointers to key architectural principles and API surfaces. - How Things Really Work
Detailed journeys through special topics in Chrome Graphics. Deep dives w/ lots of code.
Contributing
If you have experience with graphics in ChromeOS and you would like to contribute, we'd love your help in making this living document better!
The code behind this book lives in this github repo. Contributions can be made via the standard chromium gerrit workflow.
Background
Chrome Architecture
Chrome is one of the biggest and most complex open source projects on the planet. It's a project with millions of lines of code, hundreds of thousands of files, and thousands of contributors, all built over the course of more than a decade.
For someone trying to understand how Chrome is organized, all of that detail can be overwhelming.
Fortunately, if you zoom out enough, you can see the forest for the trees, and start to make sense of the project.
This section covers the important high-level details about how Chrome is organized. In it, you will learn:
- The 10,000 foot view of how Chrome is organized
- How distinct processes and threads are used to achieve security, reliability, and concurrency
- How those processes and threads communicate
- How to lift the hood and see this organization in action
Chrome on ChromeOS
As will become clear in this and the next section, ChromeOS is unique in how it is set up.
Unlike on other OSes, Chrome on ChromeOS has historically run directly on top of the kernel and managed all of the system UI. This means all the window management, settings pages, etc. get bundled into the Chrome application.
This is changing with the LaCrOS project, which separates the browser and system UI applications. Both of these are built from the same sources and are both structured as Chrome applcications, meaning that on a LaCrOS-enabled Chromebook, you're running two full Chrome applications simultaneously.
What you need to know for now is this: what's written in this section applies to Chrome on other OSes, the historical set-up on ChromeOS, and for each of the Chrome-based applcications in LaCrOS.
Processes and Threads
Architecturally, a Chrome program is a collection of specialized processes, each of which hosts specialized threads. We'll break down the responsiblities of the processes here, and leave the details for the threads
There are a few reasons for this choice:
- Security: most of the content Chrome handles is untrusted, so isolating the code that handles that content separate sandboxed makes users safer
- Reliability: Graphics code and rendering code is complicated and is built on top of even more complex systems. By doing graphics and processing work in a seperate process, crashes won't take down the whole browser and can be restarted automatically
Browser Process
This process starts first, and it is home to the Chrome UI (tabs, omnibar). It starts the other process and communicates with them over IPC to coordinate work. Less sandboxed than other processes, can do things like read and write files.
Render Processes
These processes manage instances of blink and run untrusted code from the internet. They are highly sandboxed and need to lean on the host and GPU processes to do more sensitive work.
There is one render process for every tab, and every frame in every tab.
GPU Process (AKA Viz)
This process isolates sensitive graphics tasks from the renderer. It is highly sandboxed, but has access to the graphics hardware on the device. It does things like rasterization, compositing.
Rasterization is the process of converting raw structured data into images.
Compositing is, in short, the process of combining graphical information from multiple sources into a final rendered image.
Interprocess Communication and Important APIs
ChromeOS Architecture
Processes and Threads
Core ChromeOS APIs
Wayland
CrosAPI
Skia
Color Management
Compositing Web Content
Display Management
Screenshots and Mirroring Windows
SharedImages
Contributors
This book was made with 💖 by the following folks:
Editor and Lead Author: Jim Shargo
Editor and Technichal Writer: Steve Gregersen
About
This book is built using with mdbook.
Diagrams were created with:
This book was built at revision: fafcdd2bfec312db9b0752ec3d51c057a6d7ec11