spatial-node: Flatten transforms properly.

[emilio]

This fixes Gecko bug 1512537.

Fixes #3394

---

This change is 

[emilio]

r? @kvark

Try is https://treeherder.mozilla.org/#/jobs?repo=try&revision=7220781e3ee3438ab0ec5dab5e501c262b00f0f4

[emilio]

Looks like the taskcluster failure may be a flake:

error: failed to execute compile
caused by: Failed to send data to or receive data from server
caused by: Failed to read response header
caused by: Connection reset by peer (os error 54)
error: Could not compile `osmesa-src`.

[staktrace]

Looks like the taskcluster failure may be a flake:

Yeah that's mozilla/sccache#344

[kvark]

Looks good in general, thank you!
I've got a few questions/concerns to resolve.

Reviewed 14 of 14 files at r1.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @emilio)

---

webrender/src/spatial_node.rs, line 495 at r1 (raw file):

                let should_flatten =
                    info.transform_style == TransformStyle::Flat &&
                    info.source_perspective.is_identity();

if we do have perspective, shouldn't we flatten anyway (for Flat mode), just with perspective multiplied first?

---

webrender/src/util.rs, line 573 at r1 (raw file):

impl<Src, Dst> Clone for FastTransform<Src, Dst> {
    fn clone(&self) -> Self {

I don't understand this part. Copy depends on Clone, but you implement Clone as a copy operation?

---

wrench/reftests/transforms/reftest.list, line 20 at r1 (raw file):

platform(linux) fuzzy(11,4592) == screen-space-blur.yaml screen-space-blur.png
platform(linux,mac) == nested-rotate-x.yaml nested-rotate-x.png
platform(linux,mac) != nested-rotate-x.yaml nested-rotate-x-flat.yaml

would probably make more sense to provide a png here

---

wrench/src/yaml_frame_reader.rs, line 1558 at r1 (raw file):

        info.rect = bounds;

        let transform_style = yaml["transform-style"]

don't we already read it in some place? (just a minor concern to avoid code duplication)

[emilio]

Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @kvark)

---

webrender/src/spatial_node.rs, line 495 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

if we do have perspective, shouldn't we flatten anyway (for Flat mode), just with perspective multiplied first?

No, perspective is a bit special because of how we represent it in Gecko. My patches for the perspective scrolling stuff will make this clearer.

But basically anything with perspective != [I] will only contain a single transformed ReferenceFrame kid that will do the flattening for us. Servo will need to move to such a model with my patches as well (which is the only right thing to do since the perspective item can scroll independently).

---

webrender/src/util.rs, line 573 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

I don't understand this part. Copy depends on Clone, but you implement Clone as a copy operation?

Yeah, this is just a trick to implement it without duplicating code, it can also be used to copy arrays that are bigger than 32 and other nice things :)

I need the implementation to be separate or to add bounds so that Src: Clone, Dst: Clone to the project function. I think this is better than that.

---

wrench/reftests/transforms/reftest.list, line 20 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

would probably make more sense to provide a png here

Sure, I'll do both the != and the .png comparison.

---

wrench/src/yaml_frame_reader.rs, line 1558 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

don't we already read it in some place? (just a minor concern to avoid code duplication)

Yeah, on the caller, but the same way we read transform-origin a bit below. We could pass the values from the caller I guess, but they're quite a few actually, and it probably warrants a different PR.

[kvark]

Reviewed 2 of 2 files at r2.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @emilio)

---

webrender/src/spatial_node.rs, line 495 at r1 (raw file):

Previously, emilio (Emilio Cobos Álvarez) wrote…

No, perspective is a bit special because of how we represent it in Gecko. My patches for the perspective scrolling stuff will make this clearer.

But basically anything with perspective != [I] will only contain a single transformed ReferenceFrame kid that will do the flattening for us. Servo will need to move to such a model with my patches as well (which is the only right thing to do since the perspective item can scroll independently).

if that's the assumption at this spot, let's assert on it?

---

webrender/src/util.rs, line 573 at r1 (raw file):

Previously, emilio (Emilio Cobos Álvarez) wrote…

Yeah, this is just a trick to implement it without duplicating code, it can also be used to copy arrays that are bigger than 32 and other nice things :)

I need the implementation to be separate or to add bounds so that Src: Clone, Dst: Clone to the project function. I think this is better than that.

I don't understand how this makes sense. Could you refer me to some documentation? Copy requires Clone, you shouldn't be able to implement Clone by Copy.

[kvark]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @emilio)

---

webrender/src/util.rs, line 573 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

I don't understand how this makes sense. Could you refer me to some documentation? Copy requires Clone, you shouldn't be able to implement Clone by Copy.

we played with this a bit: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6d1650f4f5b4817c3ff7e3d2dcc7b4b8

TL:DR: this is a somewhat hacky way to introduce trait chains that don't require any specific implementations
and Copy implementation requires all the fields to be Copy, in addition to the Clone bound, so that we can do it for FastTransform

[emilio]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @kvark)

---

webrender/src/spatial_node.rs, line 495 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

if that's the assumption at this spot, let's assert on it?

I don't think I can assert on it without making Servo crash. As I said I have more patches that should make this clearer, and I could fix servo then.

---

webrender/src/util.rs, line 573 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

we played with this a bit: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6d1650f4f5b4817c3ff7e3d2dcc7b4b8

TL:DR: this is a somewhat hacky way to introduce trait chains that don't require any specific implementations
and Copy implementation requires all the fields to be Copy, in addition to the Clone bound, so that we can do it for FastTransform

Sorry, was away on a CSS meeting. I assume this is fine as is? I can just do the manual cumbersome impl, but I'd rather not.

[kvark]

@bors-servo r+

[bors-servo]

📌 Commit e751100 has been approved by kvark

[bors-servo]

⌛ Testing commit e751100 with merge b5f1909...

[bors-servo]

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