Re: Async Image -> ImageData conversion

I've updated the draft with an ImageBitmap.transferToImageData() method:
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html
It's also used in Example 2 to demonstrate converting a Blob to an
ImageData without redundantly copying the pixel data.

I don't think we should extend HTMLImageElement because it is not available
in workers. Adding the conversion methods to ImageBitmap allows workers to
perform conversions using Blob (compressed image data) in the place of
HTMLImageElement.

I like the suggestion that "ImageBitmap be the hub of image conversion",
which is why I think it makes sense to add these methods to ImageBitmap and
not create() methods on other objects. In particular
transferToImageBitmap() seems like it ought to be an ImageBitmap method
since it mutates the ImageBitmap, whereas something like
ImageData.transferFrom(imageBitmap) seems unintuitive if it mutates its
parameter. If transferToImageData() belongs to ImageBitmap, I think
toImageData() logically should belong to ImageBitmap too.
ImageBitmap.toBlob() is also consistent with
HTMLCanvasElement.toBlob()/toDataURL(), where the method belongs to the
object which represents the data source.

Ashley


On 25 June 2015 at 22:10, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jun 25, 2015 at 1:57 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > 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.
>
> We should probably stick to the pattern of either having factory
> methods or putting methods directly on various objects. Or maybe,
> change them all to be static methods on the various classes:
>
>   ImageBitmap.create(...)
>   ImageData.create(...)
>   ...
>
> I would personally prefer this last pattern for creating instances
> where we need to go through a promise.
>
>
> --
> https://annevankesteren.nl/
>