Gecko Overview

1
Gecko Overview

• Chris Waterson
• ltwaterson_at_netscape.comgt
• June 10, 2002

2
Overview

• Basic data flow
• Key data structures
• Detailed walk-through
• Incrementalism
• Future tech-talks
• Wrap-up, QA

3
Basic Data Flow

• Source document arrives via network APIs
• Incrementally pumped through the
  single-threaded layout engine
• Parse, compute style, render repeat
• CSS used for rendering all content
• Content theoretically separate from presentation

4
Basic Data Flow
HTML
5
Basic Data Flow
DOM
HTML
Parser
Content Sink
Content Model
6
Basic Data Flow
DOM
HTML
Parser
Content Sink
Content Model
Style Sheets
CSS Parser
Style Rules
7
Basic Data Flow
DOM
HTML
Parser
Content Sink
Content Model
Frame Constructor
Frame Tree
Style Sheets
CSS Parser
Style Rules
8
Basic Data Flow
DOM
HTML
Parser
Content Sink
Content Model
Reflow
Frame Constructor
Frame Tree
Style Sheets
CSS Parser
Style Rules
9
Basic Data Flow
DOM
HTML
Parser
Content Sink
Content Model
Reflow
Frame Constructor
Frame Tree
Painting
Display
Style Sheets
CSS Parser
Style Rules
10
Key Data Structures
Content Node
Frame
View
Widget
1
0..n
1
0..1
1
0..1
1..n
1
Style Context

• Style context
• 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

• Content node
• Elements, attributes, leaves
• DOM
• Frame
• Rectangular formatting primitive
• Geometric information
• 0..n per content node
• 2nd thru nth are continuations

11
Key Data Structures
Content
12
Key Data Structures
Content
Frames
13
Key Data Structures
Content
Frames
Style Contexts
14
Key Data Structures
Content
Frames
Views
Style Contexts
15
Key Data Structures
Content
Frames
Views
Widgets
Style Contexts
16
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

17
Detailed Walk-Through

• Setting up
• Content model construction
• Frame construction
• Style resolution
• Reflow
• Painting

18
Setting Up

• Assume basic knowledge of embedding and network
  APIs (doc shell, streams)
• Content DLL auto-registers a Document Loader
  Factory
• _at_mozilla.org/content-viewer-factory/view1?typete
  xt/html
• All MIME types mapped to the same class,
  nsContentDLF
• nsDocShell
• Receives inbound content via nsDSURIContentListene
  r
• Invokes nsIDLFCreateInstance, passes MIME type
  to DLF
• nsContentDLF
• Creates a nsHTMLDocument object, invokes
  StartDocumentLoad.
• Creates a parser, returned as nsIStreamListener
  back to the docshell
• Creates a content sink, which is linked to the
  parser and the document
• Creates a DocumentViewerImpl object, which is
  returned as nsIContentViewer back to the docshell
• DocumentViewerImpl creates pres context and pres
  shell

19
Setting Up
nsParser
nsIStreamListener
HTMLContentSink
nsIContentSink
nsIParser
mDocument
nsDocShell
nsIDocument
mContentViewer
nsHTMLDocument
mParser
DocumentViewerImpl
mDocument
nsIContentViewer
PresContext
PresShell
20
Content Model Construction

• Content arrives from network via
  nsIStreamListenerOnDataAvailable
• Parser tokenizes processes content invokes
  methods on nsIContentSink with parser node
  objects
• Some buffering and fixup occurs here
• OpenContainer, CloseContainer, AddLeaf
• Content sink creates and attaches content nodes
  using nsIContent interface
• Content sink maintains stack of live elements
• More buffering and fixup occurs here
• InsertChildAt, AppendChildTo, RemoveChildAt

21
Content Model Construction
nsHTMLDocument
mRootContent
nsGenericHTMLElement
HTMLContentSink
mContextStack
nsIContent
mChildren
22
Frame Construction

• Content sink uses nsIDocument interface to notify
  of ?s in content model
• ContentAppended, ContentInserted, ContentRemoved
• PresShell is registered as document observer
• Receives ContentAppended, etc. notifications
• Passes these to the style set object, who in turn
  passes to the frame constructor
• Frame constructor creates frames
• ConstructFrameInternal recursively walks content
  tree, resolves style and creates frames
• Either created by tag (ltselectgt) or by display
  type (ltpgt)
• Frame manager maintains mapping from content to
  frame

23
Frame Construction
PresContext
StyleSetImpl
nsIDocumentObserver
PresShell
nsIStyleSet
mRootFrame
nsIStyleFrameConstruction
nsCSSFrameConstructor
FrameManager
Via nsFrameConstructorState
nsFrame
nsIFrame
mFirstChild, mNextSibling
24
Style Resolution

• Compute stylistic information based on the style
  rules that apply for the frames 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

25
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
  nsHTMLReflowState
• Desired size returned up via nsHTMLReflowMetrics
  
• Basic pattern
• Parent frame initializes child reflow state
  (available w, h) places child frame (x, y)
  invokes childs Reflow method
• Child frame computes desired (w, h), returns via
  reflow metrics
• Parent frame sizes child frame and view based on
  childs metrics
• N.B. many dont work like this! (Tables, blocks,
  XUL boxes)

26
Reflow

• Global reflows
• Initial, resize, style-change
• Processed immediately via PresShell method
• Incremental reflows
• Targeted at a specific frame
• Dirty, content-changed, style-changed,
  user-defined
• nsHTMLReflowCommand object encapsulates info
• Queued and processed asynchronously,
  nsIPressShellAppendReflowCommand,
  ProcessReflowCommands

27
Incremental Reflow

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

28
Incremental Reflow

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

29
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 rcs type

30
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 rcs type
• Propagate damage to frames later in the flow

31
Incremental Reflow

• Multiple reflow commands are batched
• nsReflowPath maintains a tree of target frames
• Amortize state recovery and damage propagation
  cost

32
Painting

• As reflow proceeds through the frame hierarchy,
  areas are invalidated via nsIViewManagerUpdateVi
  ew
• 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
  PresShells Paint method
• PresShellPaint walks from the view to the
  frame invokes nsIFramePaint for each layer

33
Incrementalism

• Single-threaded
• Simple (no locking)
• Cant 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

34
Incrementalism
HTML
Parser
Content Sink
Content Model
Frame Construction
Frame Tree
CSS Parser
Style Rules
Style Sheet
Main Event Loop
Reflow
Painting
Display
35
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

36
Conclusion

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