Re: Async Image -> ImageData conversion

On 6/24/15 1:28 PM, Ashley Gullen wrote:
> I'm new to specs and WebIDL, my intent was to say those are new methods
> on ImageBitmap. Is "partial interface ImageBitmap" the correct way to
> say that?

Yes, it is.

> The wording of "undue latency" in the ImageBitmap spec does not appear
> to rule out ImageBitmap storing its encoded image data, and lazily
> decoding it.

Decoding can easily take hundreds of milliseconds.  It definitely 
constitutes undue latency from our point of view.

> - require ImageBitmap to decompress its contents, and make it available
> through a read-only Uint8ClampedArray like ImageData has.

This has the premultiplied vs non-premultiplied problem Justin points out.

> - provide a way to "neuter" the ImageBitmap when converting it to
> ImageData, transferring its contents and avoiding any copy, which is
> useful if the ImageBitmap is a temporary object only being created for
> the purposes of getting the ImageData. I guess this would be similar to
> transferrable objects with workers.

This would be a viable option.

Another option is to add toBlob/toImageData directly to HTMLImageElement 
and the other things we want it on, in addition to having them on 
ImageBitmap.  Then you wouldn't need to go through an ImageBitmap at all.

> Note for devices with discrete GPUs, it's possible that ImageBitmap
> stores the decompressed image data in a GPU texture but does not have it
> in system RAM.

Indeed.  This is another situation where going directly from an 
HTMLImageElement to an ImageData or Blob would make some sense, because 
it would allow the UA to avoid the GPU upload and readback, right?

The drawback of adding toBlob/toImageData to the various things 
ImageData can be constructed from is that it's a bit more spec 
complexity, but I don't see that as a showstopper, necessarily.

-Boris

Received on Thursday, 25 June 2015 20:57:38 UTC