Disable incremental reflow for multicol and their descendants.

[SimonSapin]

Fragmentation with dynamic updates is hard.

r? @pcwalton

[highfive]

Warning

• These commits modify unsafe code. Please review it carefully!
• These commits modify layout code, but no reftests are modified. Please consider adding a reftest!

[eefriedman]

I'm not sure I understand why reconstructing the flows helps here; flow construction isn't sensitive to the width and height of each column, so you'll end up with exactly the same flow tree that you started with if, for example, the viewport is resized. What am I missing?

On a side-note, this PR doesn't build as-is.

[pcwalton]

Why not just set RECONSTRUCT_FLOW unconditionally if any MulticolFlow is present? It feels to me like the style system is the wrong place to do this, but maybe I'm missing something.

[nox]

/home/travis/build/servo/servo/components/layout/display_list_builder.rs:1798:22: 1798:57 warning: unnecessary parentheses around `for` head expression, #[warn(unused_parens)] on by default
/home/travis/build/servo/servo/components/layout/display_list_builder.rs:1798         for index in (0..self.fragments.fragments.len()) {
                                                                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/travis/build/servo/servo/components/layout/construct.rs:1327:17: 1327:45 error: no method named `in_fragmentation_container` found for type `&ConcreteThreadSafeLayoutNode` in the current scope
/home/travis/build/servo/servo/components/layout/construct.rs:1327         if node.in_fragmentation_container() {
                                                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/travis/build/servo/servo/components/layout/css/matching.rs:769:30: 772:26 error: no method named `set_in_fragmentation_container` found for type `&ConcreteLayoutNode` in the current scope
/home/travis/build/servo/servo/components/layout/css/matching.rs:769                         self.set_in_fragmentation_container(
/home/travis/build/servo/servo/components/layout/css/matching.rs:770                             parent.as_ref().map_or(false, |p| p.in_fragmentation_container()) ||
/home/travis/build/servo/servo/components/layout/css/matching.rs:771                             layout_data.shared_data.style.as_ref().unwrap().is_multicol()
/home/travis/build/servo/servo/components/layout/css/matching.rs:772                         );
/home/travis/build/servo/servo/components/layout/css/matching.rs:770:65: 770:93 error: no method named `in_fragmentation_container` found for type `&ConcreteLayoutNode` in the current scope
/home/travis/build/servo/servo/components/layout/css/matching.rs:770                             parent.as_ref().map_or(false, |p| p.in_fragmentation_container()) ||
                                                                                                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 3 previous errors
Could not compile `layout`.

[SimonSapin]

Oops, forgot to commit my latest changes. Done now.

@eefriedman the plan is to implement CSS fragmentation by having one flow for each fragment, keeping a tree structure. So one flow from flow construction can be broken up into multiple flows during layout. Without this change (or something like it), fragments would sometimes have to be pieced back together, or content moved from on fragment to another. Always going from unfragmented to fragmented is easier.

@pcwalton I didn’t know about RECONSTRUCT_FLOW, I’ll try that.

[eefriedman]

Hmm... okay, that makes some sense. That said, we probably don't want this to kick in if, for example, the color of a link changes.

[SimonSapin]

Right, we can skip layout entirely for style changes that only affect painting. That’s not specific to fragmentation.

[SimonSapin]

Is restyle damage propagated down the tree? By the time construct.rs sees RECONSTRUCT_FLOW on a multicol node, isn’t it too late to decide to reconstruct the descendant flows? (Since flow construction is bottom-up)

[SimonSapin]

Pushed another commit to sequentialize assign_block_size, as fragmentation will be intertwined with block size computation.

[bors-servo]

☔ The latest upstream changes (presumably #9051) made this pull request unmergeable. Please resolve the merge conflicts.

[bors-servo]

☔ The latest upstream changes (presumably #9110) made this pull request unmergeable. Please resolve the merge conflicts.

[SimonSapin]

Closing in favor of #9170.