More aggressively remove Fragment RestyleDamage
Now clean up damage on all fragments that belong to a Flow. This ensures
that damage does not re-propagate up to the parent Flow from the
Fragments. It also means that the flow tree dump should show a more
accurate picture of the state of the flow tree.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9008)
<!-- Reviewable:end -->
We do a few things-here:
* Hoist non-layout-dependent fields in SharedLayoutData and LocalLayoutData into style/.
* Hoist parts of css/matching.rs into style/.
* Hoist parts of layout/animation.rs into style/animation.rs.
* Remove the duplicated-but-slightly-different definition of OpaqueNode.
Now clean up damage on all fragments that belong to a Flow. This ensures
that damage does not re-propagate up to the parent Flow from the
Fragments. It also means that the flow tree dump should show a more
accurate picture of the state of the flow tree.
Use the PrintTree utility to improve the readability of flow tree
dumps. Blocks and fragments are now split over two dump levels, because
otherwise they are impenetrable. Also start printing the restyle damage of
fragments.
This flag is no longer necessary, because stacking contexts can now
create layers lazily for content that needs to be stacked above a
layer. This should reduce the number of layers on pages, hopefully
reducing overdraw.
Flows never care about their own text-align, only the text-align of
their parent; change the text-align flags to account for that. Make the
"align descendants" rule use the flags instead of the current node's style.
Fixes#7301.
Simplify stacking context creation
Have Fragment::create_stacking_context understand which stacking
contexts need layers and which do not. This simplifies the way it is
called and eliminates a bunch of code.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7804)
<!-- Reviewable:end -->
Have Fragment::create_stacking_context understand which stacking
contexts need layers and which do not. This simplifies the way it is
called and eliminates a bunch of code.
each iframe.
The old code that attempted to do this during layout wasn't able to work
for multiple reasons: it couldn't know where the iframe was going to be
on the page (because of nested iframes), and at the time it was building
the display list for a fragment it couldn't know where that fragment was
going to be in page coordinates.
This patch rewrites that code so that both the sizes and positions of
iframes are determined by the compositor. Layout layerizes all iframes
and marks the iframe layers with the appropriate pipeline and subpage
IDs so that the compositor can place them correctly. This approach is
similar in spirit to Gecko's `RefLayer` infrastructure. The logic that
determines when it is time to take the screenshot for reftests has been
significantly revamped to deal with this change in delegation of
responsibility.
Additionally, this code removes the infrastructure that sends layout
data back to the layout task to be destroyed, since it is now all
thread-safe and can be destroyed on the script task.
The failing tests now fail because of a pre-existing bug related to
intrinsic heights and borders on inline replaced elements. They happened
to pass before because we never rendered the iframes at all, which meant
they never had a chance to draw the red border the tests expect to not
render!
Closes#7377.
Currently pseudo-elements, like the fragments created for ::before and
::after, with layers will have the same LayerId as the body of their
owning fragments. Instead all LayerIds should be unique.
Fixes#2010.
layout: Defend the block formatting context speculation against going wrong in the presence of blocks that overflow in the inline direction.
Makes the Google search result links appear.
Closes#7298.
r? @mbrubeck
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7550)
<!-- Reviewable:end -->
StackingContexts that should be painted on top of StackingContexts that
are already layerized should automatically get their own layer. This
will ensure proper painting order.
layout: Make overflow calculation take relative percentages into account.
This necessitated changing overflow to be calculated by the parent flow
if relatively positioned children are present. That is because the
overflow regions cannot be calculated without knowing relative offsets,
which themselves cannot be calculated without knowing the parent size
(because of percentages). To accomplish this without sacrificing
parallelism in the non-relative case, this patch splits overflow into
"early" and "late" computation. Late overflow computation cannot be
parallelized across children, while early overflow computation can.
Makes the "Apple Music" text show up over the full-bleed promotional
background on apple.com.
r? @SimonSapin -- would appreciate a look over the iframe test case that was changed.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7313)
<!-- Reviewable:end -->
account.
This necessitated changing overflow to be calculated by the parent flow
if relatively positioned children are present. That is because the
overflow regions cannot be calculated without knowing relative offsets,
which themselves cannot be calculated without knowing the parent size
(because of percentages). To accomplish this without sacrificing
parallelism in the non-relative case, this patch splits overflow into
"early" and "late" computation. Late overflow computation cannot be
parallelized across children, while early overflow computation can.
Makes the "Apple Music" text show up over the full-bleed promotional
background on apple.com.
layers in the fragment, so that it can be activated when we're forcing
the creation of extra layers due to positioned descendants that
themselves have layers.
The newly failing tests were tests that accidentally passed due to
incorrect stacking order.
Closes#7281.
layout: Use the value of the `max-width` property when speculating what the inline sizes of block formatting contexts are likely to be.
Usually, Web developers set this property on block formatting contexts
in order to avoid running into floats, and we can use this as a
speculation hint.
Fixes the width of the search box on the Google SERPs.
r? @mbrubeck
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7256)
<!-- Reviewable:end -->
