Separate interning Image & YuvImage

[djg]

In support of #3385, extract Image and YUVImage. This patch is based up PR #3392 and requires that to land first.

---

This change is 

[djg]

Try & talos: https://treeherder.mozilla.org/#/jobs?repo=try&revision=27cbd66f358a757efa654b7b6804e95610b207a0

[gw3583]

Could you rebase this to remove the patches that have landed now?

[djg]

Could you rebase this to remove the patches that have landed now?

Done

[gw3583]

Reviewed 9 of 9 files at r1.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @djg)

---

webrender/src/prim_store/mod.rs, line 2587 at r1 (raw file):

                // write_segment(yuv_image_data, *segment_instance_index, frame_state, scratch);
                debug_assert!(*segment_instance_index != SegmentInstanceIndex::INVALID);
                if *segment_instance_index != SegmentInstanceIndex::UNUSED {

Let's try to find a way to not duplicate these code blocks.

---

webrender/src/prim_store/mod.rs, line 2716 at r1 (raw file):

                //write_segment(image_data, image_instance.segment_instance_index, frame_state, scratch);
                if image_instance.segment_instance_index != SegmentInstanceIndex::UNUSED {

Same here

[djg]

It appears that the osx-release taskcluster job failed to start. I've restarted it.

[gw3583]

That last commit seems a bit more complex (esp. the cache fn) than I was thinking it would be, but I haven't looked in detail yet - I might just be missing something.

The general idea of the GpuCacheRequest being a by-value type is that it should work around the borrowck issues that way. I'll pull the branch today and see if I can provide some more useful comments than the vague details above, sorry!

[djg]

That last commit seems a bit more complex (esp. the cache fn) than I was thinking it would be, but I haven't looked in detail yet - I might just be missing something.

The general idea of the GpuCacheRequest being a by-value type is that it should work around the borrowck issues that way. I'll pull the branch today and see if I can provide some more useful comments than the vague details above, sorry!

@gw3583, in the previous incarnation of the code there was a split borrow of the prim fields and the borrowck was happy. It's unhappy with:

if Some(foo) = gpu_cache.bar(&self.common.gpu_handle) {
    ...
    self.write_prim_gpu_blocks(...);
    ...
}

because it can't see that fn write_prim_gpu_blocks() doesn't access self.common.

I welcome a second set of 👀 on the code.

[gw3583]

This is roughly what I was thinking [1] - does that seem like it should achieve the same outcome and work for the rest of the prim types?

[1] gw3583@a6910bc

[djg]

Reviewable status: 2 of 9 files reviewed, 3 unresolved discussions (waiting on @gw3583)

---

webrender/src/prim_store/mod.rs, line 963 at r1 (raw file):

write_prim_gpu_blocks

---

webrender/src/prim_store/mod.rs, line 2587 at r1 (raw file):

Previously, gw3583 (Glenn Watson) wrote…

Let's try to find a way to not duplicate these code blocks.

Done.

---

webrender/src/prim_store/mod.rs, line 2716 at r1 (raw file):

Previously, gw3583 (Glenn Watson) wrote…

Same here

Done.

[djg]

@gw3583 Are we good to proceed with these changes?

[gw3583]

Yup, I think so - do we need another try / talos run or should this be good to go?

[gw3583]

@bors-servo delegate+

[bors-servo]

✌️ @djg can now approve this pull request

[djg]

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5b13864afb0efce11588f4427603cc5c73cbf31c

[bors-servo]

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

[gw3583]

@bors-servo delegate+

[bors-servo]

✌️ @djg can now approve this pull request

[djg]

@bors-servo r=gw

[bors-servo]

📌 Commit 0541e3c has been approved by gw

[bors-servo]

⌛ Testing commit 0541e3c with merge 1126699...

[bors-servo]

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