Port image primitives to use interning.

[gw3583]

This change is 

[gw3583]

This is a large patch - it's mostly shuffling code around to make it work with interning. It also includes #3349, and may be simpler to review after that lands.

This is quite untidy in places - we're taking on a bit of technical debt here to get stuff ported to interned primitives and enable picture caching. Once that is in place, it will definitely be worth a tidy up pass over these new structures, to tidy up the interfaces and pack the structures better.

r? @kvark or @nical

[gw3583]

Try run is here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6cf0b7225af4e51b2107d3ada2644b12ffae2fd1&selectedJob=213758505

There is 1/255 pixel difference in a couple of tests on Windows. These same tests are marked fuzzy on other renderers, so we can do the same here. There is a perma-crash in 'C' - that is unrelated to this patch (see https://bugzilla.mozilla.org/show_bug.cgi?id=1509635#c11 for details). The other couple of failures look to be unrelated intermittents.

[kvark]

Reviewed 5 of 5 files at r2.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @gw3583)

---

webrender/src/batch.rs, line 1419 at r2 (raw file):

                };

                let specified_blend_mode = BlendMode::PremultipliedAlpha;

why are we always using premultiplied here?

---

webrender/src/batch.rs, line 1763 at r2 (raw file):

                let image_instance = &ctx.prim_store.images[*image_instance_index];
                let opacity_binding = ctx.prim_store.get_opacity_binding(image_instance.opacity_binding_index);
                let specified_blend_mode = match alpha_type {

it would be nice to not re-define the variable. I find it confusing (and one of the most arguable Rust language features). Let's either have mut or with a different name. In some cases, re-defining is fine if the body of the function isn't big, or at least the re-defining happens within the vicinity of the first definition (e.g. acceptin an Option<> in a function and then getting its contents), but not in this case.

---

webrender/src/batch.rs, line 1768 at r2 (raw file):

                };
                let request = ImageRequest {
                    key: *key,

is key pattern matched by ref implicitly? why are we explicitly putting ref source then?
those implicit refs, uh

[bors-servo]

☔ The latest upstream changes (presumably #3349) made this pull request unmergeable. Please resolve the merge conflicts.

[gw3583]

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

---

webrender/src/batch.rs, line 1419 at r2 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

why are we always using premultiplied here?

Because the only remaining primitives in this legacy path are the gradients, which have a specified blend mode of premultiplied alpha (previously was coming from the get_blend_mode method). The specified blend mode is kind of like CSS specified properties - it can still get overridden below to be opaque based on various other properties.

---

webrender/src/batch.rs, line 1763 at r2 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

it would be nice to not re-define the variable. I find it confusing (and one of the most arguable Rust language features). Let's either have mut or with a different name. In some cases, re-defining is fine if the body of the function isn't big, or at least the re-defining happens within the vicinity of the first definition (e.g. acceptin an Option<> in a function and then getting its contents), but not in this case.

I don't think this does re-define the variable? Each of the definitions of specified_blend_mode is in a separate branch of the match {}

---

webrender/src/batch.rs, line 1768 at r2 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

is key pattern matched by ref implicitly? why are we explicitly putting ref source then?
those implicit refs, uh

Yea, it's implicit. I removed the ref on source for consistency.

[gw3583]

Thanks @nical and @kvark. Rebased this on master and addressed the review comments above.

[kvark]

@bors-servo r+

[bors-servo]

📌 Commit 37e9435 has been approved by kvark

[bors-servo]

⌛ Testing commit 37e9435 with merge 05d4ecc...

[bors-servo]

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