Browser_and_Render.md

Browser and Render

Dive into browser architecture and rendering flow.

Resources

1. Chromium architecture overview
2. How Blink works
3. Life of a pixel(Video|PPT)

Chromium Architecture

Chromium is a multi-process browser

Chromium has one browser process and N sandboxed renderer processes

1. Browser process
   • main process, startup process, broker process
   • Main thread
     • render browser UI
   • I/O thread
     • communicate with other process
   • N Worker threads
     • run tasks, like DNS lookup
     • there exists a worker pool to add/remove threads dynamically
2. Sandboxed renderer process
   • Usually one process per tab
     • because of the performance, no 1:1 mapping between renderer processes, iframes and tabs
   • Main thread (runs Blink)
     • render web content
     • JavaScript, CSS, DOM
   • I/O thread
     • communicate with browser process
     • from the view of renderer process, the browser process is a set of services
   • N worker threads
     • Web Workers
     • Service Workers
     • Workerlets
   • Internal threads
     • web audio
     • database
     • GC

Concepts

1. A Page corresponds to a concept of a tab
   • Renderer process : Page = 1 : N
2. A Frame corresponds to a concept of a frame (the main frame or an iframe)
   • Page : Frame = 1 : M
3. A DOMWindow corresponds to a window object in JavaScript
   • Frame : DOMWindow = 1 : 1
4. A Document corresponds to a window.document object in JavaScript
   • DOMWindow : Document = 1 : 1
5. An ExecutionContext is a concept that abstracts a Document (the main thread) and a WorkerGlobalScope (a worker thread)
6. e.g., iframe.contentWindow.location.href = "https://example.com";
   • original Page
   • original Frame
   • new DOMWindow
   • new Document
   • new ExecutionContext

Render Flow

From an HTML file to pixels in the screen

Pipeline

1. HTML

   <div>
       <p> hello </p>
       <p> world </p>
   </div>

2. Parse HTML: HTML -> DOM
   • HTMLDocumentParser
   • HTMLTreeBuilder
3. DOM (document object model)

   - Document
     - HTML
       - BODY
         - DIV
           - P
             - Text
           - P
             - Text
   

   • contains shadow DOM
4. Style

   /* rules */
     p { /* selector */
       color: red; /* declaration: property + value */
     }

5. Parse Style: Style -> StyleSheetContents
   • CSSParser
6. StyleSheetContents

   type CSSProperty = Color | ...;
   type CSSValue = CSSColorValue | ...;
   
   type CSSPropertyValue = {
     Property: CSSProperty;
     Value: CSSValue;
   }
   type StyleRule = {
     CSSSelectorList: CSSSelector[];
     CSSPropertyValueSet: CSSPropertyValue[];
   };
   type StyleSheetContents = StyleRule[];

7. Style Calculation: StyleSheetContents + DOM -> ComputedStyle
   • Style recalc: for every node in the DOM tree, compute the value of every style property
   • Document::UpdateStyle
   • StyleResolver::ResolveStyle
   • JS: getComputedStyle(element)["propertyName"]
8. DOM with ComputedStyle (CSSOM?)

   - Document          + ComputedStyle
     - HTML            + ComputedStyle
       - BODY          + ComputedStyle
         - DIV         + ComputedStyle
           - P         + ComputedStyle
             - Text    + ComputedStyle
           - P         + ComputedStyle
             - Text    + ComputedStyle
   

9. Layout: DOMTree -> LayoutTree -> FragmentTree
   • Computes the exact position and size of each object
     • Block box and inline box
     • Normal flow. floats and absolute
     • Text font, size, family
     • Overflow and scrollable
   • StyleEngine::RebuildLayoutTree
   • LocalFrameView::UpdateLayout
10. Layout Tree: ready to layout

    - Document       --> - LayoutView      
      - HTML         -->   - LayoutBlockFlow        
        - BODY       -->     - LayoutBlockFlow      
          - DIV      -->       - LayoutBlockFlow     
            - P      -->         - LayoutBlockFlow     
              - Text -->           - LayoutText
            - P      -->         - LayoutBlockFlow     
              - Text -->           - LayoutText
    

    • DOM nodes are not 1:1 with layout objects.
      • usually, one DOM node gets one LayoutObject
      • a node -> no LayoutObject: display: none;
      • a node -> more than one LayoutObject: inline box with text before and after a block box(demo)
      • no node -> a LayoutObject: Anonymous block boxes and Anonymous inline boxes
11. FragmentTree: layout result
    • Walks the layout tree, computing the visual geometry of each LayoutObject

    Box (block-flow) at 0,0 100x12
      Box (block-flow children-inline) at 0,0 100x54
        LineBox at 24.9,0 0x18
          Box (floating block-flow children-inline) at 0,0 24.9x34
            LineBox at 8,8 8.9x18
              Text 'F' at 8,8 8.9x17
          Text '\n' at 24.9,0 0x17
        LineBox at 24.9,18 67.1x18
          Text 'The ' at 24.9,18 28.9x17
          Text 'quick' at 53.8,18 38.25x17
        LineBox at 0,36 69.5x18
          Text 'brown' at 0,36 44.2x17
          Text ' fox' at 44.2,36 25.3x17
      Box (block-flow children-inline) at 80,-6 20x18
        LineBox at 0,0 39.125x18
          Text 'jumps' at 0,0 39.125x17
    

12. Paint: FragmentTree -> PaintOperation[]
    • Paint records paint operations into a list of display items.
    • Paint elements in stacking order (controlled by z-index)
    • Paint runs in multiple phases, each paint phase is a separate traversal of a stacking context.
    • LocalFrameView::PaintTree
13. Raster(Compositor thread): PaintOperation[] -> ColorBitmap
    • Raster can be accelerated by the GPU process
14. Draw(Compositor thread)
    • Display content with GPU process

Changes

1. Each pipeline stage tracks granular asynchronous invalidations.
   • Style -> Node::SetNeedsStyleRecalc()
   • Layout -> LayoutObject::SetNeedsLayout()
   • Paint -> PaintInvalidator::InvalidatePaint()
   • Raster -> RasterInvalidator::Generate()
2. Layers
   • New stacking context will promote a layout object to a layer
   • Main thread will decompose the page into layers before paint
   • Compositor thread will raster layers independently and composite them into one
   • The compositor can handle input events like scroll, clip, scale, ...
3. Compositing Assignments
   • Build layers before paint in the main thread
   • PaintLayerCompositor::UpdateAssignmentsIfNeeded
4. Pre-paint
   • Build the property trees before paint in the main thread
   • PrePaintTreeWalk::Walk
   • PaintPropertyTreeBuilder
   • The property trees contain various properties for a layer
     • overflow
     • clip
     • transform
     • ...
   • The compositor can apply them to a layer

Rendering Optimization

1. Recap the render pipeline: Style -> Layout -> Paint -> Composite
   • Main thread: Style, Layout, Paint
   • Compositor thread: Composite
2. Whole pipeline: some properties will reflow the page
   • Geometry: width, height, top, left, padding, margin, ...
   • Position: float, display, position, flex, ...
   • BFC Changing: overflow
3. Skip Layout: some properties are "paint only"
   • Visual: background, color
   • Stacking Context Changing: z-index, opacity
4. Only Composite: best performance!
   • Layer properties: transform, opacity
   • Promote elements with will-change or translateZ
   • Avoid layer explosions
5. Resources
   • CSS Triggers: A CSS property will trigger which render flow