1 / 36

Gecko Overview

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

sharla
Télécharger la présentation

Gecko Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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. Content node Elements, attributes, leaves DOM Frame Rectangular formatting primitive Geometric information [0..n] per content node 2nd thru nth are “continuations” 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 Key Data Structures Content Node 1 0..n Frame 1 0..1 View 1 0..1 Widget 1..n 1 Style Context

  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 • @mozilla.org/content-viewer-factory/view;1?type=text/html • All MIME types mapped to the same class, nsContentDLF • nsDocShell • Receives inbound content via nsDSURIContentListener • Invokes nsIDLF::CreateInstance, 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 nsIStreamListener nsParser nsIContentSink HTMLContentSink nsIParser mDocument nsDocShell nsIDocument mContentViewer nsHTMLDocument mParser DocumentViewerImpl mDocument nsIContentViewer PresContext PresShell

  20. Content Model Construction • Content arrives from network via nsIStreamListener::OnDataAvailable • 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 HTMLContentSink nsGenericHTMLElement 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 (<select>) or by display type (<p>) • Frame manager maintains mapping from content to frame

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

  24. 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

  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 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)

  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, nsIPressShell::AppendReflowCommand, ProcessReflowCommands

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

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

  29. 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

  30. 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

  31. Multiple reflow commands are batched nsReflowPath maintains a tree of target frames Amortize state recovery and damage propagation cost Incremental Reflow

  32. Painting • As reflow proceeds through the frame hierarchy, areas are invalidated via nsIViewManager::UpdateView • 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 PresShell’s Paint method • PresShell::Paint walks from the view to the frame; invokes nsIFrame::Paint for each layer

  33. 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

  34. Incrementalism HTML Parser Content Sink Content Model Frame Construction Frame Tree Style Sheet CSS Parser Style Rules 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?

More Related