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

Nomnoml diagram missing. Check the console for more details.

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