Image resizing API

[glennw]

Currently, once an image is created you cannot resize it. But this makes the API complicated to use when you need to resize (e.g. in the case of a canvas texture).

One option could be to pass a field on image creation that states if the image is immutable or may change size. That could give WR a hint to choose appropriate texture storage depending on the likely resize patterns of this image.

[glennw]

Thoughts @kvark ?

[asajeffrey]

This came up in the context of servo/servo#17278.

[kvark]

e.g. in the case of a canvas texture

Canvas is sort of special. It's typically big enough to deserve it's own texture anyway, so that we can not bother caring about the resize in texture allocator. Are there any other prominent examples of the need for resize? If canvas is the only thing, then I think it would be simpler to treat everything as storage-immutable on the WR side and expect the ImageId to be re-generated for canvas resizes and such.

[asajeffrey]

We are thinking of redoing the canvas implementation anyway (servo/servo#17497) which would probably make this change unnecessary.

[nical]

Another use case is rendering blob images at the resolution of the screen while zooming. Currently blob images have a fixed resolution and we'd need to re-create the blob image as we zoom. Might not be extremely important, though, since I think that Firefox doesn't yet support async zoom on desktop (so we re-build the display list each frame during zoom, and can re-create the blob image along the way), but it would be nice to not have to rebuild the entire display list just because a blob image needed to get a new ImageKey in order to change its resolution when we ship webrender on android (nice but not necessary).

Considering how easy it is to support changing image sizes in the resource cache, I'd rather just support it there than move the complexity to the user of the API (and have to re build display lists just for that when we could avoid it).

[kvark]

@nical
Now that I look at it, there doesn't appear to be any fundamental problem of updating the same key with an entirely new data (new size/format). update_image_template would need to detect his and re-allocate the new space in texture cache accordingly.

[glennw]

This is resolved.