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
