Re: Async Image -> ImageData conversion

On Fri, Jun 26, 2015 at 7:07 AM, Ashley Gullen <ashley@scirra.com> wrote:

> 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 I am not mistaken, ImageBitmaps were not intended to be mutated. So far
I always assumed the intended behavior of transferToImageBitmap() was that
it created a new ImageBitmap. The difference with createImageBitmap is that
the transfer semantic guarantees zero copying, which implies that the
source object has to be neutered. transferToImageBitmap should only be
necessary for transferring from objects that have mutable pixels data
(ImageData, canvas).


> 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/
>>
>
>