Overview

• Review of reflow
• Table frames
• Table reflow
• Intro to paganated reflow
• Table paganated reflow
• Areas not covered

Review of Reflow

• Reflow process starts when
  • An html document starts loading (the frame tree contains only viewport, scroll(s), canvas, html, body).
  • The initial chunk of an xml doc is loaded.
  • The initial chunk of an html doc (or a subsequent chunk of an xml doc) is loaded. The container posts a dirty reflow command with itself as the target.
  • Content is inserted, appended, or deleted through the DOM. The container posts a dirty reflow command with itself as the target.
  • Style changes through the DOM - javascript, browser change font (CTRL+/-), a preference changes, etc.

Review of Reflow

• Reflow starts with pres shell which reflows the reflow root (usually the view port frame), which reflows it children, etc.
• Ususally it starts when the pres shell processes its queue of reflow commands.
• The reflower
  • Positions reflowee (if it can) before actually reflowing in case views are involved
  • Reflows reflowee and passes a reflow state (in) and a reflow metrics (in/out)
• the reflow state
  • Is a node in a tree structurally equavalent to the frame tree of reflow paticipants
  • contains reflow type, avail size, various computed values, resolved style structs
  • possible request for preferred size and more.

Review of Reflow

• The reflowee sets various sizes in the reflow metrics after (possibly) reflowing some or all of its children which reflows it children, etc.
• max element size (if requested) - the minimum size it can be
• preferred size (if requested) - the size it would like to be given no size constraints.
• desired size - the size it would like to be given the avail size. This is equavalent to preferred size if the avail size is not constrained.
• The reflowee returns a reflow status which indicates
  • if it is complete, and thus not have to continue (split)
  • breaking status (in the case of some inline frames)
  • if there is truncation (it can't fit in the space and can't split). This is just a convience mechanism.

Kinds of reflows

• initial - reflowee's first reflow must be of this type (reflower's responsibility).
• resize - reflowee gets a change in available space only. Similar to initial, except it can reoccur.
• incremental - has a reflow path (tree) where each node has a command with a target frame, reflow command types are:
• dirty - something changed inside a target (e.g. it gains, loses children)
• style changed - a target changed stylisticly (recall, size is a style property)
• content changed - a target's content changed (e.g. a text run)
• user defined - currently only used for fixed positioned frames

Kinds of reflows

• incremental reflow
  • reflower not allowed to change available size of reflowee
  • reflow commands get coalesced to streamline processing
• style change
  • a target changed stylistic if there is a target, otherwise every frame may need to respond
  • parent of target usually turns it into an incremental reflow with a style changed command type

Table Frames

Table Reflow

• outer table reflows table and caption (if present)
• table reflows row groups in multiple passes
• Pass 1 - unconstrained width, height and requests max elem width.
• The table figures out the column widths (balances) given the style width constraints on the table, row groups, rows, cells the preferred and max element sizes of the cells (from the pass 1 reflow), and considers colspans
• Pass 2 - cell widths are constrained by the column widths (heights are only constrained in paganated mode).
• The row group figures out the row heights given the its style height constraints its rows and cells and the actual heights of its rows and cells from the pass 2 reflow
• If the table has a style height, it allocates extra height to its row groups, rows and cells.
• in each pass, row groups reflow rows which reflow cells which reflow cell blocks

Table Reflow

Table reflow optimizations

• If the table already balanced, pass 1 constrains the width (like a normal pass 2) based on the current column widths. The pass 2 will get skipped if the table doesn't need to rebalance.
• Nested table reflowed with an unconstrained width (i.e. an ancestor is doing a pass 1 reflow) will only do a pass 1 reflow on its children
• Outer table caches last avail width and avoids reflowing children if resize reflow is the same as previous
• Table caches max element, preferred widths in case they are requested and it isn't rebalanced
• Cell caches prior avail width. if this doesn't change, the row may not have to reflow the cell

Table incremental reflow

• Outer table is a target when a caption is added or removed (dirty) or the table or caption margin changes (style changed).
• Caption is a target when it changes stylistically (style changed).
• Table, row group, row, col group, col is a target when a child is added or removed (dirty) or it changes stylistically (style changed).
• In the dirty cases, a target posted the reflow command in AppendFrames, InsertFrames, or DeleteFrame.

Table incremental reflow

• In the style change cases where a target is between the table and the cell, the table is told to rebalance.
• When a target is the cell or below and the cell changes size, the row tells the table so it can decide if it needs to rebalance
• When a target is inside the cell's block, the cell requests max element, preferred sizes of its block in case they change
• After the table reflows the row group(s) containing the targets, if it rebalances, it then does a pass 2 reflow.

Special height reflow

• When there is a % height frame inside a cell without a computed height
• the frame will never get a chance to size based on the final cell height
• in paganated mode when there is a height on the table, the table doesn't allocate extra height to rows until after it does a pass 2 reflow and then it is too late
• This can be fixed by doing a special 3rd pass reflow

Special height reflow

Special height reflow

Special height reflow

• The reflow state holds an observer and initiator
• observer
• is the table cell used as the height basis
• set by frame without computed height in DidReflow
• gives its block a computed height during 3rd pass
• doesn't change height during 3rd pass
• initiator
• is the table containing the observer
• starts the 3rd pass reflow and sets a bit in the reflow state
• gives its block a computed height during 3rd pass
• could also be inside a cell which is an observer

Special height reflow

• optimizations
• only frames needing 3rd pass actually get it
• frames gettting a 3rd pass only get it once

Intro to paganated reflow

• When a reflowee's available height is constrained, it may not fit and need to either split/continue on the next page, or start on the next page.
• If it can continue, it returns an incomplete status.
• If it can't continue it returns a complete status.
• A continuation may also need to be continued
• Continuations are linked together by prevInFlow and nextInFlow pointers

Intro to paganated reflow

Intro to paganated reflow

• The page sequence starts with one page and reflows it. If the page is incomplete then the page sequence creates a continuation for the page and sets it as the page's next sibling (it is also the page's nextInFlow).
• The page was incomplete because the page content was incomplete because the doc root was incomplete
• The doc root was incomplete because it contained lines that didn't fit (or if it was mapped to a table, because the table didn't fit) becacause a line contained something that didn't fit, etc.

Intro to paganated reflow

• If the reflowee is incomplete, the reflower has the responsiblity to:
  • Create a continuation for the reflowee
  • Ensure that the continuation gets put in the frame hierarchy at the right place and gets reflowed at the right time.
  • Typically, a reflower accomplishes this by putting the continuation (c) on an overflow list which the reflower owns. When the reflower's continuation gets reflowed, it takes c and its siblings as children and reflows them.
• If the reflowee is complete, truncated (it didn't fit), not at the top of page, the reflower should put the reflowee on its overflow list and return an incomplete status.

Intro to paganated reflow

• Special assumptions
  • There are only initial and (possibly) resize reflows. Incremental and style change reflows are not allowed.
  • Multiple resize reflows may be necessary (e.g. a child is truncated and gets reflowed on a subsequent page) but they should not change the available width from the last time.
  • Multiple resize reflows may require special handling if a frame split previously. It may need to "pull up" children from a continuation.

Table paginated reflow

• The block containing the outer table reflows it. If it is incomplete, the block will
  • create a continuation for the outer table (which also creates a continuation for the table).
  • put the continuation on a new line and place that line on its overflow lines property.
• The outer table reflows the table and just returns the status of the table.
• The table does a pass 1 reflow and balances. If it is incomplete,
• it will become the first-in-flow
• it will be the only frame among its continuations to ever balance or calc the cell map, and it only does this once

Table paginated reflow

• The table does a pass 2 reflow constraining both avail heights and widths. If a row group is incomplete, the table
  • creates a continuation for the row group
  • puts the continuation in its overflow frames property
• What follows only applies during the pass 2 reflow.
• The row group
• reflows all of its rows with unconstrained heights and calculates the row heights,
• figures out which row falls on a page boundary and reflows it with a constrained height. If there will be a pass 3 reflow then this should (bug) happen at that time instead.
• creates a continuation for incomplete the row (which also creates continuations for all of its cells and all of the cell blocks)
• puts the continuation in its overflow frames property. If the row was truncated and not top of page, the row is put in the overflow frames property.

Table paginated reflow

• The row and cells (getting the constrained height reflow) just reflow their children with a constrained height. They don't need an overflow list for continued children because the continuations were created when the row group created the row's continutation.
• A cell is incomplete because its block is incomplete. The block uses the overflow lines mechanism (mentioned above) for its continued children
• There are two splitting scenarios for a table
  • An incomplete cells block causes the cell, row, row group, table, outer table to be incomplete
  • A truncated row or a row that started too far down the page causes the row group, table, outer table to be incomplete.

Managing style contexts

• Style contexts must (in most cases) be created before frames are constructed, to determine what frame to create.
• Parent style context determines inheritance; it should always be the content parent. [design flaw in frame/SC relationship]
• Three functions for creating style contexts on nsIStyleSet, wrapped by similarly named ones on nsIPresContext:
  • ResolveStyleContextFor: For elements.
  • ResolvePseudoStyleContextFor: for pseudo-elements (:first-letter, :before, etc.)
  • ResolveStyleContextForNonElement: skips rule matching and uses root rule node (text frame optimization)

Managing style contexts

• Style context resolving functions will walk the rule processors in StyleSetImpl::FileRules, find the correct rule node, and find a current child of the parent (“sibling sharing”) or create a new child.
• Style context doesn't hold pointer to content, just rule node.

Dynamic changes to content

• FrameManager::ReResolveStyleContext destroys and recreates style contexts for existing frames (rule node pointer immutable).
• ReResolveStyleContext is messy because it needs to create and parent style contexts correctly (sibling sharing may not be the same) rather than just changing data. [design flaw, again]
• Any specially-parented style contexts (not along frame parents, which need not be content parents) are reconstructed using nsIFrame::GetParentStyleContextFrame.
• Can return same style context due to sibling sharing unless we're destroying the rule tree for a style sheet/rule removal.

Dynamic changes to content

• ReResolveStyleContext calculates differences (repaint, reflow, reframe, etc.) between style old and new style contexts and does appropriate cleanup
• It uses nsIStyleContext::CalcStyleDifference, which only computes differences for structs that have been requested. (I'll call this the data-struct-based hint mechanism.)
• Caller of nsIFrameManager::ComputeStyleChangeFor processes the change list, which has been built to avoid duplication.
• We also have ReParentStyleContext, used in a few places (usually during frame construction), but it's broken (has many bugs that ReResolveStyleContext used to have).

Dynamic changes to content: optimizations

• We optimize attribute changes by storing all the attributes that have an effect on which rules match and only doing a ReResolveStyleContext if the attribute has an effect. nsIStyleSheet::AttributeAffectsStyle (should be on nsIStyleRuleProcessor).
• We optimize event state changes (:hover, :active, etc.) using nsIStyleRuleProcessor::HasStateDependentStyle, which is much more accurate. The CSSRuleProcessor implementation does a slightly modified form of selector matching to implement it (includes matching on the middle of selectors to catch p:hover a).

Style attribute changes

• We handle style attribute (“inline style”) changes in a different way from other changes to style rules.
• As for other style changes, we have to “walk” the rule tree and clear all the style data coming from the old inline style nsIStyleRule, since there could be an !important rule that overrides it, which would allow dynamic changes to put the style attribute in multiple places in the rule tree. However, we maintain a hashtable just for inline style rules so that we don't have to walk the whole tree to find the nodes.
• nsCSSFrameConstructor::AttributeChanged only reresolves style on the subtree of the element, just like other attribute changes.
• Different hint mechanism (from rule structs, not data structs) could make AttributeChanged just go straight to a framechange, instead.
• Bugs due to failure to call nsIFrame::DidSetStyleContext.

Style sheet addition and removal

• Handled in pres shell.
• PresShell::ReconstructStyleData calls FrameManager::ComputeStyleChangeFor (ReResolve) and then processes the framechange list.
• Rebuilds rule tree if stylesheet was removed to avoid dangling pointers (and perhaps aliasing that would cause problems). Otherwise we'd have to walk rule tree and compare each rule node to every rule in the sheet (O(rules * rule-nodes)).
• When rebuilding rule tree, we have to clear cached style contexts from XUL menus and trees.

Style rule changes

• Handling of style rule changes is done in frame constructor (called from style set, called from pres shell, which is a document observer) and in the pres shell. Code should be merged.
• Rule change applies the rule-struct hint as if the rule matched the root element. (inefficient) It does clearing of style data (through StyleSetImpl::ClearStyleData) by walking the rule tree and then the style context tree. (could be handled by simultaneous clearing and difference calculation of data (somewhat tricky))
• Rule addition and removal just rebuild the entire world. We could at least do what we do for sheet addition/removal, or slightly better, by searching the rule tree (only one rule this time) instead of rebuilding it.
• Lots of room for optimization here. (but beware DidSetStyleContext)

The style system