@@ -119,9 +158,8 @@
Review of reflow
Table frames
Table reflow
- Intro to paganated reflow
- Table paganated reflow
- Areas not covered
+ Intro to paginated reflow
+ Table paginated reflow
@@ -263,7 +301,7 @@
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).
+ constrained in paginated 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.
@@ -278,7 +316,65 @@
<
>
- Table Reflow
+ Table Reflow Example
+
+
+
+
+tblO 030176CC r=0 a=8940,UC c=0,0 cnt=429
+ tbl 030178C4 r=0 a=8940,UC c=4470,UC cnt=430
+ rowG 03017A7C r=0 a=UC,UC c=UC,UC cnt=431
+ row 03017C08 r=0 a=UC,UC c=UC,UC cnt=432
+ cell 03017DA8 r=0 a=UC,UC c=UC,UC cnt=433
+ block 03017E08 r=0 a=UC,UC c=UC,UC cnt=434
+ block 03017E08 d=870,300 me=480
+ cell 03017DA8 d=930,360 me=540
+ cell 0301A8CC r=0 a=UC,UC c=UC,UC cnt=436
+ block 0301A92C r=0 a=UC,UC c=UC,UC cnt=437
+ block 0301A92C d=1335,300 me=465
+ cell 0301A8CC d=1395,360 me=525
+ row 03017C08 d=UC,360
+ rowG 03017A7C d=UC,360
+ rowG 03017A7C r=2 a=4470,UC c=4470,UC cnt=442
+ row 03017C08 r=2 a=4470,UC c=4470,UC cnt=443
+ cell 03017DA8 r=2 a=1755,UC c=1695,UC cnt=444
+ block 03017E08 r=2 a=1695,UC c=1695,UC cnt=445
+ block 03017E08 d=1695,300
+ cell 03017DA8 d=1755,360
+ cell 0301A8CC r=2 a=2625,UC c=2565,UC cnt=446
+ block 0301A92C r=2 a=2565,UC c=2565,UC cnt=447
+ block 0301A92C d=2565,300
+ cell 0301A8CC d=2625,360
+ row 03017C08 d=4470,360
+ rowG 03017A7C d=4470,360
+ tbl 030178C4 d=4500,450
+ tblO 030176CC d=4500,450
+ |
+
+
+<table width=300>
+ <tr>
+ <td>foo</td>
+ <td>bar zap</td>
+ </tr>
+</table>
+
+
+
+
+Key:
+
+ r = reflow reason,
+ 0 (initial),
+ 2 (resize)
+ a = avail w, h
+ c = computed w, h
+ d = desired w, h
+ me = max elem w
+
+ |
+
+
@@ -341,7 +437,7 @@
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
+
- in paginated 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
@@ -355,7 +451,43 @@
<
>
Special height reflow
+ Special Reflow Example
+
+
+
+
+<table border=2 width=300>
+ <tr>
+ <td>
+ This cell's width is
+ constrained by the
+ table and image widths.
+ Its exact height is
+ hard to determine.
+ </td>
+ <td>
+ <img src=raptor.jpg
+ width=200 height=100%>
+ </td>
+ </tr>
+</table>
+
+ |
+
+
+
+ | This cell's width is constrained
+ by the table and image widths. Its height
+ is hard to determine.
+ |
+ 
+ |
+
+
+
+ |
+
- Intro to paganated reflow
+ Intro to paginated 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.
@@ -431,7 +563,81 @@
<
>
- Intro to paganated reflow
+ Pagination Illustration
+
+ | nsSimplePageSequence |
+
+
+
+ | nsPageFrame |
+
+
+
+ | nsPageContentFrame |
+
+
+
+ | areaFrame (html) |
+
+
+
+ | blockFrame (body) |
+
+
+
+ | nsTableOuterFrame |
+
+ |
+
+
+ |
+
+
+ |
+
+
+ |
+
+ |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ |
+
+ | nsTableOuterFrame |
+
+ |
+
+ | blockFrame (body) |
+
+ |
+
+ | areaFrame (html) |
+
+ |
+ | nsPageContentFrame continued |
+
+ |
+
+ | nsPageFrame continued |
+
+ |
+
+
- Intro to paganated reflow
+ Intro to paginated 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
@@ -455,7 +661,7 @@
<
>
-
Intro to paganated reflow
+ Intro to paginated reflow
- If the reflowee is incomplete, the reflower has the responsiblity to:
@@ -477,7 +683,7 @@
<
>
- Intro to paganated reflow
+ Intro to paginated reflow
- Special assumptions
@@ -547,7 +753,7 @@
-
-
- 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
-
-
- Style sheets & rules
↓
- Rule tree
↓
- Style context interface
-
- |