Gecko Overview Chris Waterson watersonnetscape com June 10

Gecko Overview Chris Waterson <waterson@netscape. com> June 10, 2002

Overview • • • Basic data flow Key data structures Detailed walk-through Incrementalism Future tech-talks Wrap-up, Q&A

Basic Data Flow • Source document arrives via network APIs • Incrementally “pumped” through the singlethreaded layout engine – Parse, compute style, render; repeat – CSS used for rendering all content • Content theoretically separate from “presentation”

Basic Data Flow HTML

Basic Data Flow DOM HTML Parser Content Sink Conten t Model

Basic Data Flow DOM HTML Parser Style Sheets Content Sink Conten t Model CSS Parser Style Rules

Basic Data Flow DOM HTML Parser Content Sink Conten t Model Frame Constructor Style Sheets CSS Parser Style Rules Fram e Tree

Basic Data Flow DOM HTML Parser Content Sink Conten t Model Reflow Frame Constructor Style Sheets CSS Parser Style Rules Fram e Tree

Basic Data Flow DOM HTML Parser Content Sink Conten t Model Reflow Frame Constructor Style Sheets CSS Parser Style Rules Fram e Tree Painting Display

Key Data Structures Content Node 1 0. . n Frame 1 0. . 1 View 1 0. . 1 Widget 1. . n 1 Style Context • Style context • Content node – Elements, attributes, leaves – DOM • Frame – – Rectangular formatting primitive Geometric information [0. . n] per content node 2 nd thru nth are “continuations” – Non-geometric information – May be shared by adjacent frames – Reference counted, owned by frame • View – Clipping, z-order, transparency – [0. . 1] per frame, owned by frame • Widget – Native window – [0. . 1] per view, owned by view

Key Data Structures Content

Key Data Structures Content Frames

Key Data Structures Content Frames Style Contexts

Key Data Structures Content Frames Style Contexts Views

Key Data Structures Content Frames Style Contexts Views Widgets

Key Data Structures • The document owns the content model, and one or more presentations – Exposed programmatically via DOM APIs • The presentation owns the frame hierarchy – Frames own the style contexts, views, widgets – Presentation has media type, dimensions, etc. – May not be directly manipulated

Detailed Walk-Through • • • Setting up Content model construction Frame construction Style resolution Reflow Painting

Setting Up • Assume basic knowledge of embedding and network APIs (doc shell, streams) • Content DLL auto-registers a Document Loader Factory – @mozilla. org/content-viewer-factory/view; 1? type=text/html – All MIME types mapped to the same class, ns. Content. DLF • ns. Doc. Shell – Receives inbound content via ns. DSURIContent. Listener – Invokes ns. IDLF: : Create. Instance, passes MIME type to DLF • ns. Content. DLF – Creates a ns. HTMLDocument object, invokes Start. Document. Load. • Creates a parser, returned as ns. IStream. Listener back to the docshell • Creates a content sink, which is linked to the parser and the document – Creates a Document. Viewer. Impl object, which is returned as ns. IContent. Viewer back to the docshell • Document. Viewer. Impl creates pres context and pres shell

Setting Up ns. IStream. Listener ns. Parser ns. IContent. Sink HTMLContent. Sink ns. IParser m. Document ns. Doc. Shell ns. IDocument m. Content. Viewer ns. IContent. Viewer m. Parser Document. Viewer. Impl Pres. Context ns. HTMLDocument m. Document Pres. Shell

Content Model Construction • Content arrives from network via ns. IStream. Listener: : On. Data. Available • Parser tokenizes & processes content; invokes methods on ns. IContent. Sink with parser node objects – Some buffering and fixup occurs here – Open. Container, Close. Container, Add. Leaf • Content sink creates and attaches content nodes using ns. IContent interface – Content sink maintains stack of “live” elements – More buffering and fixup occurs here – Insert. Child. At, Append. Child. To, Remove. Child. At

Content Model Construction ns. HTMLDocument m. Root. Content HTMLContent. Sink m. Context. Stack ns. IContent ns. Generic. HTMLElement m. Children

Frame Construction • Content sink uses ns. IDocument interface to notify of s in content model – Content. Appended, Content. Inserted, Content. Removed • Pres. Shell is registered as document observer – Receives Content. Appended, etc. notifications – Passes these to the style set object, who in turn passes to the frame constructor • Frame constructor creates frames – Construct. Frame. Internal recursively walks content tree, resolves style and creates frames – Either created by tag (<select>) or by display type (<p>) • Frame manager maintains mapping from content to frame

Frame Construction Pres. Context ns. IDocument. Observer Pres. Shell ns. IStyle. Set. Impl m. Root. Frame ns. IStyle. Frame. Construction Frame. Manager Via ns. Frame. Constructor. State ns. IFrame ns. CSSFrame. Constructor ns. Frame m. First. Child, m. Next. Sibling

Style Resolution • Compute stylistic information based on the style rules that apply for the frame’s content node • Style data broken into different structures – Display, visibility, font, color, background, … – Inherit vs. reset • Style context object is a placeholder for partially computed stylistic data – Style data is computed lazily, as it is asked for

Reflow • Recursively compute geometry (x, y, w, h) for frames, views, and widgets – Given w & h constraints of “root frame” compute (x, y, w, h) for all children – Constraints propagated “down” via ns. HTMLReflow. State – Desired size returned “up” via ns. HTMLReflow. Metrics • Basic pattern – Parent frame initializes child reflow state (available w, h); places child frame (x, y); invokes child’s Reflow method – Child frame computes desired (w, h), returns via reflow metrics – Parent frame sizes child frame and view based on child’s metrics • N. B. many don’t work like this! (Tables, blocks, XUL boxes)

Reflow • “Global” reflows – Initial, resize, style-change – Processed immediately via Pres. Shell method • Incremental reflows – – Targeted at a specific frame Dirty, content-changed, style-changed, user-defined ns. HTMLReflow. Command object encapsulates info Queued and processed asynchronously, ns. IPress. Shell: : Append. Reflow. Command, Process. Reflow. Commands

Incremental Reflow • Recursively descend to target recovering reflow state – Child rs. reason set to incremtenal

Incremental Reflow • Recursively descend to target recovering reflow state – Child rs. reason set to incremental

Incremental Reflow • Recursively descend to target recovering reflow state – Child rs. reason set to incremental • Process reflow “normally” at target frame – Child rs. reason set based on rc’s type

Incremental Reflow • Recursively descend to target recovering reflow state – Child rs. reason set to incremental • Process reflow “normally” at target frame – Child rs. reason set based on rc’s type • Propagate damage to frames later “in the flow”

Incremental Reflow • Multiple reflow commands are batched – ns. Reflow. Path maintains a tree of target frames – Amortize state recovery and damage propagation cost

Painting • As reflow proceeds through the frame hierarchy, areas are invalidated via ns. IView. Manager: : Update. View • Unless immediate, invalid areas are coalesced and processed asynchronously via OS expose event • Native expose event dispatched to widget; widget delegates to the view manager • View manager paints views back-to-front, invoking Pres. Shell’s Paint method • Pres. Shell: : Paint walks from the view to the frame; invokes ns. IFrame: : Paint for each layer

Incrementalism • Single-threaded – Simple (no locking) – Can’t leave event queue unattended • Content construction unwinds “at will” – Parser and content sink do some buffering – Content sink has “notification limits” – Efficiency vs. responsiveness trade-off • • Frame construction runs to completion CSS parsing runs to completion Reflow runs to completion (mostly) Painting runs to completion

Main Event Loop Incrementalism HTML Parser Content Sink Style Sheet CSS Parser Style Rules Reflow Painting Display Conten t Model Frame Construction Frame Tree

Future (? ) Tech Talks • • • Content model and DOM - jst, jkeiser Parser and content sink (esp. invalid content) - harishd Events - saari, joki Block-and-line reflow - waterson, dbaron Table reflow - karnaze Form controls - rods, bryner Style resolution and rule tree - dbaron Views, widgets, and painting - roc, kmcclusk Editor - kin, jfrancis XUL and box layout - hewitt, ben XBL - hewitt, ben

Conclusion • • • Data flow Key data structures Detailed walk-through Incrementalism Q & A?