commit c0b406d151940c4253d59c041d895e763c27e754
author Morten Stenshorne <mstensho@chromium.org> Tue Jul 13 14:47:18 2021
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Tue Jul 13 14:58:16 2021
tree 70ecd5183e7b4f7d8dc3fbd51b5a27149cff2578
parent 2a570cfa1f41bf3f40cd967cf45620b157b65c8b

PrePaint: LayoutObject traversal with LayoutNG fragment lookups.

Almost completely move away from fragment traversal in pre-paint.
Instead do LayoutObject traversal accompanied by a corresponding
NGPhysicalBoxFragment when possible. This means that we'll keep track of
the fragment of the parent LayoutObject at any given time, and, when
entering a child LayoutObject, we'll search that fragment for a child
fragment (or child fragment item) representing a child LayoutObject.
If we don't find the child, it means that it doesn't exist in the
current fragmentainer.

One piece of complexity here is out-of-flow positioned elements. Since
we're traversing the LayoutObject tree, and keep track of the fragment
of the parent LayoutObject, for OOFs, we also need to keep track of the
ancestor fragments that may contain absolutely or fixed positioned
descendants, and search them, rather than the parent fragment, when
looking for OOFs. We also need to make paint offset adjustments when
entering OOFs, since OOFs are direct children of a fragmentainer, rather
than a child of their actual containing block.

There are still a few cases where it's just too hard to avoid fragment
traversal, though:

1. OOF fragments with missing containing block fragments. This happens
when an OOF inside block fragmentation overflows its actual containing
block, and occurs in fragmentainers where the containing block doesn't
occur.

2. Fragmented floats inside inline formatting contexts, when the float
occurs in fragmentainers where some of its ancestors don't.

3. Column spanners are always entered directly from the ancestor
multicol container.

When we fall back to fragment traversal like this, we'll also miss any
paint effects that should be caused by the missing ancestors. The new
test external/wpt/css/css-break/transform-009.html is failing because of
this. See crbug.com/1224888 . We might want to revisit this later if
important enough, but it will require large changes to how we lay out
OOFs in block fragmentation.

This CL fixes as many as *one* existing test. Added a few new ones that
previously didn't pass (except for the one mentioned above). This CL
fixes a few things:

1. Apply paint effects caused by parents not in the containing block
chain (e.g. on an abspos inside opacity inside relpos).

2. Handle transforms correctly for OOFs inside multicol.

3. Clear paint invalidation flags for text and non-atomic inlines, so
that if someone dirties them, we'll actually mark the tree properly, and
recalculate paint properties and invalidate for paint as necessary.

virtual/layout_ng_fragment_traversal/external/wpt/css/CSS2/positioning/
toogle-abspos-on-relpos-inline-child.html is now failing. See
crbug.com/1225304

Updated css/css-break/out-of-flow-in-multicolumn-035.html to add some
transform translation, to test fixedpos inside abspos in multicol. This
test now fails with legacy block fragmentation.

Remove NGFragmentChildIterator, since this was only used as a helper for
fragment traversal in pre-paint. It helped us access incoming break
tokens very easily. We cannot use it for LayoutObject traversal. We
still need the incoming break token in a couple of relatively rare
cases, and we'll just find it manually there. This isn't exactly cheap,
but I believe that, at some point in the future, we won't need incoming
break tokens at all during painting (only during layout).

As part of reducing the need for incoming break tokens, we'll no longer
use the "flow thread offset" as an ID in FragmentData in NG (in fact, we
were abusing this field by storing consumed block-size instead of flow
thread offset). Instead we'll use the fragmentainer index, which is
easier and cheaper to obtain. PaintInfo will now map from
NGPhysicalBoxFragment to FragmentData in more cases than before, rather
than comparing fragment IDs. The only case in NG where we need to map
using the fragment ID is for self-painting non-atomic inlines (which
don't store a vector of physical fragments in the layout object).

Bug: 1043787, 1205685
Change-Id: I63f5b9bc07d45770a728f6d125baf02800863aa5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2996982
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901004}