Add support for large images.

[glennw]

This will need some kind of API support to handle very large images, as well as supporting scrolling / partial images.

[kvark]

We could split a large image into equally sized tiles and store them in a texture array (as proposed by @glennw ), similarly to #645 .
Both proposals would require the shaders to become aware of 2D texture array sources.

[nical]

Ideally we would lazily upload visible parts of the large image to textures. Currently gecko does not do this (we just split up the big image into tiles and upload them all) and we end up allocating silly amounts of GPU memory for something that tends to only be partially shown.

If using texture arrays is too complicated we could just split all images into small tiles and use the texture cache as usual generating a bit more geometry. With small enough tiles this could become an optimization for images that are partially off the viewport without being too big to fit into a texture.
For reference, FastUIDraw uses a sparse virtual texture for this type of things.

[nical]

I am looking into this. I'll first work on getting the logic in place to split large images into smaller ones and and make sure these sub primitives are requested and uploaded lazily. But it will still use the texture cache like regular images. Whether and how to use texture arrays for this is something that can be solved separately.

[nical]

The first issue I am running into is that it is pretty hard to support repeating images once their tiled. One way to work around this is to have two fallbacks for large images: one that down-scales on the CPU before inserting in the texture cache, and one that does the actual tiling. we'd only use the tiling for non-repeating image display items.

Another way to look at it is to simply not support repeating large images, which is probably reasonable*.

In any case it is not entirely clear to me whether we should hide the tiling inside of WR, or if it should be explicitly requested in the API when creating the image. I started working with the former in mind but I now am leaning towards doing the latter instead.

*edit: We talked about it during the gfx meeting today and it turns out we need to support repeating very large images, and preferably without downsampling.

[glennw]

@nical I think this can be closed?

[nical]

Yes, this is fixed now.