Fix z-ordering of transformed content inside preserve-3d context.

[glennw]

When a 3d rendering context is established, add an extra picture
(that is never composited to an intermediate surface). This extra
pictures serves as a 3d rendering context container.

Add a normal picture as a child of that container which is marked
as using an intermediate surface. Any untransformed content that
is included as part of the 3d rendering context will be placed in
here, and be rendered in the correct order. If no untransformed
content is added, then this picture won't be allocated and will
have no effect on intermediate surface allocation.

This gets us some ordering and correctness fixes. It still doesn't
dynamically avoid plane-splitting when it's not needed. However,
with this in place, and the recent changes to add PictureState,
adding this optimization will be relatively simple.

Fixes #2337.

---

This change is 

[glennw]

Gecko try has 2 unexpected FAILs:

https://hg.mozilla.org/try/rev/3fa54312cc0c33f14a9cbbc8bb0ab181e3e66bf1
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fa54312cc0c33f14a9cbbc8bb0ab181e3e66bf1

I'll investigate these in the morning.

[staktrace]

I looked at the mask-layer-3.html failure, and that one at least is a gecko bug. The gecko DL for the <div id="c"> has an empty clipchain, but in gecko land it inherits the clips from enclosing items which include the clip with the rounded corners. When we translate this DL to a WR DL we don't explicitly generate any clip for that item - however there is a stacking context introduced by <div id="b"> and so that makes it so that the rounded-corner clip doesn't get inherited down. This is something I can fix on the gecko side as part of my clipping rewrite to use the new clip chains API.

[glennw]

I investigated the other test failure. Interestingly in this case, the main reftest draws correctly, it is the -ref file that fails to draw anything. I recorded the Gecko DL and reduced the test case to the YAML below. In this case, the display list appears to have set the transform-style to preserve-3d but there is no preserve-3d in the source HTML file (for the -ref image).

So I think that points to a Gecko DL bug, but ideally @staktrace could verify that.

If that's the case, then both the unexpected FAILs here are Gecko DL bugs, and this should be ready for review and merge. r? @kvark

---
root:
  items:
    -
      type: "stacking-context"
      items:
        -
          bounds: [0, 0, 1887, 1971]
          "clip-rect": [0, 0, 1887, 1971]
          type: clip
          id: 1
          "content-size": [1887, 1971]
        -
          "clip-rect": [0, 0, 1887, 1971]
          "clip-and-scroll": 1
          type: "scroll-frame"
          id: 2
          "content-size": [1887, 1971]
          bounds: [0, 0, 1887, 1971]
        -
          bounds: [0, 0, 1887, 1971]
          "clip-rect": [0, 0, 1887, 1971]
          "clip-and-scroll": 2
          type: clip
          id: 3
          "content-size": [1887, 1971]
        -
          "clip-and-scroll": 2
          type: "stacking-context"
          filters:
            - opacity(0.5)
          items:
            -
              "clip-and-scroll": 3
              type: "stacking-context"
              transform: [1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 12, 150, 0, 1]
              "transform-style": "preserve-3d"
              perspective: [1, 0, 0, 0, 0, 1, 0, 0, -0.6, -0.6, 1, -0.006666667, 0, 0, 0, 1]
              items:
                -
                  "clip-and-scroll": 3
                  type: "stacking-context"
                  transform: [1, 0, 0, 0, 0, 0, -1, 0, 0, 1, 0, 0, 0, 180, 90, 1]
                  items:
                    -
                      bounds: [0, 0, 180, 180]
                      "clip-rect": [0, 0, 180, 180]
                      "clip-and-scroll": 3
                      type: rect
                      color: 255 0 255 1.0000

[glennw]

(The clip and scroll here for the inner element looks wrong too, I think - similarly to the other test failure?)

[staktrace]

@glennw Yeah that seems like a Gecko bug

[glennw]

Thanks, so I think this should be fine to merge once the review is done, and we'll add 2 new failure annotations to the WR update.

r? @kvark

[kvark]

Reviewed 4 of 4 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

webrender/src/frame_builder.rs, line 480 at r1 (raw file):

                .iter()
                .rev()
                .find(|sc| sc.rendering_context_3d_prim_index.is_some())

wouldn't this be the same primitive ID as self.picture_stack.lat().unwrap()?

---

webrender/src/frame_builder.rs, line 561 at r1 (raw file):

        }

        if participating {

let's rename to something like participate_in_plane_split

---

wrench/reftests/split/ordering.yaml, line 5 at r1 (raw file):

  items:
    -
      type: "stacking-context"

how does the original code handle this case? where do things go wrong?

---

Comments from Reviewable

[glennw]

Review status: 3 of 4 files reviewed at latest revision, 3 unresolved discussions.

---

webrender/src/frame_builder.rs, line 480 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

wouldn't this be the same primitive ID as self.picture_stack.lat().unwrap()?

It would be in the first level of a preserve-3d hierarchy, but not if you have a nested preserve-3d (since the primitive ID there is only stored as Some(..) when an establishing 3d context is found).

---

webrender/src/frame_builder.rs, line 561 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

let's rename to something like participate_in_plane_split

Done.

---

wrench/reftests/split/ordering.yaml, line 5 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

how does the original code handle this case? where do things go wrong?

The original code in batch.rs draws all the un-transformed content first, then the planes that were participating. The spec says that the untransformed content should be drawn on a plane at z=0 and interact with the other plane splits.

---

Comments from Reviewable

[glennw]

@kvark Thanks, comments addressed.

[kvark]

Sounds good, thank you!
@bors-servo r+

[bors-servo]

📌 Commit e980335 has been approved by kvark

[bors-servo]

⌛ Testing commit e980335 with merge 7809537...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster, status-travis
Approved by: kvark
Pushing 7809537 to master...

[staktrace]

@glennw This PR seems to have caused windows debug jobs to start failing in gecko CI - see last part of https://bugzilla.mozilla.org/show_bug.cgi?id=1434723#c6. Not really sure why, there's no obvious root cause in the log.

Also FYI I updated https://wiki.mozilla.org/Platform/GFX/Quantum_Render#Try_syntax to include windows in the try push syntax - I neglected to do this when we added the windows jobs, sorry!

[staktrace]

Actually it might be a gecko-side problem. See comment 7.