1

Workweek incremental layout

Josh Matthews edited this page 2014-07-07 17:45:20 -07:00

Table of Contents

• Incremental Layout

Incremental Layout

• jack: gw was worried about overlap with cow dom.
• gw: I was thinking that it will be easy to supply lists to layout of DOM nodes that have changed. wondered if it would be useful for incremental layout.
• pcwalton: not sure I want to do it that way, due to parallel layout. when a node is changed, would like to set a is_dirty flag and propagate has_dirty_descendents upwards. when laying out, only restyle descendents marked dirty. in some cases may need to restyle nodes not marked dirty due to weird css selectors.
• gw: figured that COW DOM could supply that information, since you implicitly know dirty set. sounds like minor overlap.
• pcwalton: (something about enqueueing parallel traversal) by following bit flags you already know this. in general you only traverse parts of the dom that have been marked dirty, using has_dirty. flow construction right now is done by taking every node's layout data pointer to flow, bubble all flows up the dom tree, and incremental layout takes old construction results and using them as you go up the tree - if node isn't dirty, you can use old result. takes time proportional to depth of the tree, but that shouldn't be too bad. eventually need to have concept of changing certain css properties doesn't invalidate flow, just painting for example.
• jack: is it possible to have it not invalidate the display item, just change the color?
• pcwalton: would need persistent display items. would like basic stuff right now, like changing position of absolute item doesn't change (?)
• jack: can we test this once we add it?
• pcwalton: gecko uses async reftests with script that modifies original content, reference is final state, compare to ensure that incremental change is correct.
• jack: can we test speed instead of correctness?
• pcwalton: no idea.
• gw: for correctness, could dump flow tree too. could be interesting.
• mbrubeck: could set flags somewhere that says "layout ran" just for testing purposes.
• jack: how do we expose this to script?
• pcwalton: window.performance.servoLayoutWhatever
• mbrubeck: could we load servo as a library in the test harness instead?
• pcwalton: probably easier to expose this way
• jack: I just want to make sure that we don't regress after we add this. gw, any concerns?
• gw: no, it seems like a small enough overlap that it is not a problem.
• jack: will you just work on the layout part, or do incremental display list stuff too?
• pcwalton: just layout, don't want to step on mrobinson's toes. we have code for this already, but it's buggy and it doesn't do anything since we lack incremental reflow. as a followup, want to look at gecko's flags to cause reflow for non-dirty things. do we know what webkit does? I think the only issue is sibling selectors - if you change a node, you may need to invalidate sibling nodes.
• zwarich: webkit keeps all flags on render object, since it's persistent.
• pcwalton: we want to copy gecko's changehints that specify what needs to be done. want more fine-grained, but not for the first cut.

(various questions related to animations/layers/opacity/textures and webkit)

• pcwalton: hoping to have incremental reflow done by tomorrow. next step is dirty bit propagation.
• jack: that's the stuff kmc wrote last year?
• pcwalton: that's at a different level; that's more like changehints. we need dirty bits on dom node that tell the layout task to skip recreating the flow. when dom nodes have strong references to flows, it should be easy to add. good test for this is resizing wikipedia - should not set any dirty bits, so should be very quick.
• jack: can we avoid width recalc when changing vertical height?
• pcwalton: that will break with vertical writing modes, among other things. not sure it's a good optimization.