browser-architecture

Notes from “A Guest to be a (web)master” by Mariko Kosaka

This talk focuses on the architecture for Chrome
Divided into different processes, such as
- Browser process - handles navigation requests, some UI etc
- Render process - Handles rendering web content
- Plugin process - handles external plugins like flash
- Utility processes, etc
Each process can spin up multiple threads
Each process talks to others via inter-process communication
Service workers make cdecision on what gets cached, what is sent to storage, which requests need to be made etc
- JS code and is run by the render process

Loading and parsing
- Reads HTML, sends requests for additional assets and scripts with URLs found in the document
- Results in a DOM tree
- If a R:js file is found, this thread will pause, get the JS, execute it and then consinue reading HTML (this is why JS is generally tagged at the bottom)
- You could mess with this sequence by setting resource priority to things
- After this CSS is read and computed CSS is generated
Layout
- Where are the linebreaks going to be - this affects sizes of elements and everything positioned after it
- Creates a Layout Tree (not the same as DOM tree)
- Layout trees include pseudo content like stuff in the `:before, :hover` selectors
Paint
- Go throuhg the layout tree an create paint records
Raster
- Modern browsers use composites - browsers split the elements into layers (much like photoshop), and raster them separately
- For dynamic pages, all the browser has to do is move layers that have already been rasered, instead of re-rendering entire pages for simple scroll action
- Uses a Layer Tree for this - hint to the browser with a will-change property

Takes data from the raster thread and proceeds to display
Page is divided into tiles, and each tile is rendered separately using an exclusive Raster Thread
Each Raster Thread takes a small piece of the page, turns it into a GPU texture and puts into GPU memory, while keeping a reference in the compositor thread
Compositor knows where the viewpoirt is, so it should schedule threads to render tiles within viewport first; creating a Compositor Frame
This gets sent to the Browser Process, which adds Browser UI to the frame and sends it to the GPU
When scrolling happens, Browser Pricess sends this to compositor thread, which returns a new compositor frame
How do event handlers in JS talk to this render system?
- While compositing, parts of DOM are marked as non-scrollable. When these bits have to be rendered, compositor will pause and ask main thread
- {passive: true} can be used to prevent compositor from pausing for event handlers