Port linear gradients to be interned primitives.

[gw3583]

This change is 

[gw3583]

This patch is not tidy, but not quite as bad as it looks, since it includes #3349 and #3350 - probably best to review this after those have been reviewed and merged.

Pending try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fdad847f558535e816874e76b788bed727a7707e

[gw3583]

Try run looks good so far. Also seems to be about another 2% win in dl_mutate (https://treeherder.mozilla.org/perf.html#/graphs?series=try,1660472,1,1&selected=try,1660472,407537,652574374).

[kvark]

a few suggestions are below

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

---

webrender/src/border.rs, line 1133 at r3 (raw file):

pub fn create_nine_patch_segments(
    rect: &LayoutRect,
    nine_patch: &NinePatchDescriptor,

could this be a method of this descriptor?

---

webrender/src/prim_store.rs, line 422 at r3 (raw file):

impl Eq for GradientStopKey {}

impl hash::Hash for GradientStopKey {

would it be easier to just introduce a HashFloat? we'd not need to manually derive Hash for anything else then. We'd even use TypedSize2D<HashFloat, ...> and TypedPoint2D<HashFloat, ..> for a number of things here

---

webrender/src/prim_store.rs, line 2691 at r3 (raw file):

pub type ImageInstanceStorage = storage::Storage<ImageInstance>;
pub type ImageInstanceIndex = storage::Index<ImageInstance>;
pub type GradientTileStorage = storage::Storage<VisibleGradientTile>;

why do we need all those typedefs? IIRC, they were helpful when the indices weren't strongly typed. Now everything is explicit enough. Is it just to save on symbol count?

[bors-servo]

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

[gw3583]

Reviewable status: 0 of 8 files reviewed, 3 unresolved discussions (waiting on @kvark)

---

webrender/src/border.rs, line 1133 at r3 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

could this be a method of this descriptor?

Yep, done.

---

webrender/src/prim_store.rs, line 422 at r3 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

would it be easier to just introduce a HashFloat? we'd not need to manually derive Hash for anything else then. We'd even use TypedSize2D<HashFloat, ...> and TypedPoint2D<HashFloat, ..> for a number of things here

Yep, sounds good. That's probably a good approach to switch to when tidying all this up.

---

webrender/src/prim_store.rs, line 2691 at r3 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

why do we need all those typedefs? IIRC, they were helpful when the indices weren't strongly typed. Now everything is explicit enough. Is it just to save on symbol count?

Initially I was just following the initial code which had typedefs, but I agree - I'm fine with changing them to be explicit types. OK if we do that later on, to avoid rebase issues with the other open PRs?

[gw3583]

Rebased and fixed one of the review comments. I agree with the other two suggestions too - although would prefer to do those as follow ups, to avoid rebase issues with other open patches.

[kvark]

@bors-servo r+

[bors-servo]

📌 Commit b9dda49 has been approved by kvark

[bors-servo]

⌛ Testing commit b9dda49 with merge 604c69a...

[kvark]

My things TODO after picture caching is here is growing and growing ;)

[gw3583]

My things TODO after picture caching is here is growing and growing ;)

#3357

[bors-servo]

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