commit 568c6e76ff51bb3fb2bd2c1ff9e9986ad789dc3d
author L. David Baron <dbaron@chromium.org> Wed Dec 01 18:58:58 2021
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Wed Dec 01 19:05:15 2021
tree d351db47dff27e58f2f793901a8e9e95d86ade96
parent 5103a35d4471b8f4e7f05506bea68300154d00d3

Make 3D leaf render pass decision compatible with TransformInterop.

The decision about when to create a render pass at the leafward edges of
preserve-3d scenes was not compatible with the changes to preserve-3d
made in TransformInterop in a number of ways.

With TransformInterop, being the leaf of a 3D scene (where we define
leaf as the element *all* of whose descendants are flattened into it)
does not require any unusual properties on the element; it merely
requires that the parent have transform-style: preserve-3d but the
element not do so.  (Prior to TransformInterop, it required something
that created a node in the transform tree; see NeedsTransform().)

Doing this correctly post-TransformInterop requires that we make the
decision about whether an element is in this flattening position in the
effect node in the paint property tree while we're still operating on
layout objects and have accurate information about element parent/child
relationships.

This also avoids a case in the old code (which I'm not convinced was
bug-free in this respect prior to TransformInterop) where the code could
get set state on an effect node when operating on a transform node that
was a descendant of that effect node's transform node (but one that
shared the same effect node).

This continues to make the render surface associated with the closest
possible element to the 3D scene.  I considered trying to move it
further away, but this seems difficult both because it must end up with
the 3D scene's sorting context set on the quad (for the containing
render pass) that draws the render pass, and because it must contain
anything that creates render pass quads.

REVIEW: I'm hopeful that this doesn't create any z-ordering bugs
(between things in separate flattened leaf elements of the same 3D scene
that should interleave with each other), although it's possible it will.
The tests I've written appear to pass, although it's not entirely clear
why they pass.  (Conceptually what we really want is to create a single
render surface, associated with the parent of the leaves, for *all* of
its leaf children, but not including any preserve-3d children.)

Note that the existing web test
compositing/overflow-trumps-transform-style.html is the only test that
fails if this code to cause creation of a render pass is removed.

The newly-added tests preserve3d-and-flattening-00{1,2,3}.html fail
prior to this change.   001 is the one that is closest to the broken
site; it does not fail if the code to create a render pass is just
removed.  002 and 003, however, also fail if the code is removed.  (The
distinction between 002 and 003 was needed to get more complete test
coverage with multiple earlier versions of this change.)

The newly-added tests preserve3d-and-flattening-z-order-001 through -007
test aspects of z-order interleaving.  In particular, -006 and -007
showed failures with earlier versions of this patch.

All of the newly added tests pass in Firefox and Safari, although in
some cases this may be because they're testing the wrong thing because
those engines still need to make some or all of the changes that we
shipped in TransformInterop.

Note that the rebaselining of the following highdpi expectations also
rebaselines to fix existing failures prior to this change:
flag-specific/highdpi/paint/invalidation/compositing/squashing-inside-preserve-3d-element-expected.txt
flag-specific/highdpi/compositing/layer-creation/no-compositing-for-preserve-3d-expected.txt
flag-specific/highdpi/compositing/3d-cube-expected.png

Fixed: 1255544
Cq-Include-Trybots: luci.chromium.try:mac10.12-blink-rel,mac10.13-blink-rel,mac10.14-blink-rel,mac10.15-blink-rel,mac11.0.arm64-blink-rel,win7-blink-rel
Change-Id: I4d8ae4c6a134cc1605188779760079be1e9c7f90
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3212140
Commit-Queue: David Baron <dbaron@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#947118}