Re: Async Image -> ImageData conversion

Gosh, I keep putting the wrong terms in and it really confuses things. I
need to get better at writing clearly! I mentioned "transferToImageBitmap"
when I meant "transferToImageData". The parargraph from my second-last
email should read:

====
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 transferToImageData()
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.
====

I understand that ImageBitmaps were not intended to be mutated, but the
OffscreenCanvas proposal is already suggesting that there be a close()
method (to immediately release it), and that they be transferrable (which
mutates them on the thread they are transferred from). These appear to be
essential requirements for the OffscreenCanvas proposal to work
efficiently. If we are going to have this anyway, then it seems reasonable
to use the same mechanism for ImageBitmap.transferToImageData(). Also there
is still no direct access to the ImageBitmap pixel data, it's only mutable
in the sense it can be reset to empty.

The same thing could happen for ImageData.transferToImageBitmap(), where
the ImageData is neutered and it returns an ImageBitmap which can share the
same storage, but I guess this is less controversial since ImageData is
already mutable.




On 26 June 2015 at 14:10, Justin Novosad <junov@google.com> wrote:

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