[WIP] External image handlers

[kvark]

WebRender does not have a single "client". It can be used by multiple independent actors, which may, for example, manage their respective namespaces, or populate/present different documents. Therefore, WR needs to support multiple external image handlers, where each external image is strongly associated with one.

WIP, because TODO: Gecko patch and try push
Edit: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a1fa7748d33f862bb25dc86fad8e091631328484

@glennw comments and r?

---

This change is 

[kvark]

I think Servo would prefer the API to be more in line with generate_external_image_namespace followed by set_external_image_handler(namespace, handler), so I'm going to rework it a bit.

[glennw]

The general idea here seems fine, and the implementation looks good. I'll take another look after your suggested changes for Servo.

[kvark]

@glennw thanks for taking a look! I figured the simplest way here would be if a handler could be assigned per IdNamespace (without the need for an extra ExternalImageNamespace type).

[glennw]

Right, that would probably be ideal :)

[kvark]

app_units crate fails to compile on nightly - requires feature(clamp) to be enabled

[kvark]

@glennw AppVeyor failures aside (unrelated), and while Gecko push is pending, please take another look as the approach is changed a bit.

[glennw]

Looks good. If this covers the use case that Gecko needs, then r=me.

[glennw]

@kvark I guess we'll want to remove the handler if the api namespace goes out of scope. Not a big deal though - we can work that out as a follow up.

[kvark]

we'll want to remove the handler if the api namespace goes out of scope

Sure, good point. Fixed now :)

If this covers the use case that Gecko needs, then r=me.

It's not covering Gecko needs at this very moment as much as it's needed for smooth WebGPU prototyping (WebGL and WebGPU don't want to share the same handler).

[kvark]

@glennw I switched back to new-typed external hander IDs after talking to @jrmuizel about possible future use in Gecko. However, producing an actual patch/try-push for Gecko seems to require a ton of plumbing in this case, so that's where I am now.

[glennw]

@kvark This looks fine to me. Is it ready to go from your perspective?

[kvark]

@glennw thanks!
I haven't got the time to produce a Gecko patch yet (as noted earlier, it's not trivial). I don't think we should be merging this without a patch and try-push.

[bors-servo]

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

[glennw]

Closing for now - feel free to re-open when you have time to work on this again :)