W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Async Image -> ImageData conversion

From: Ashley Gullen <ashley@scirra.com>
Date: Fri, 26 Jun 2015 12:08:37 +0100
Message-ID: <CAABs73hTqKPuPOzmasPG9+NKGY5nG_epaJtEMCsJ6j+dGuk7zg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>, Jeff Muizelaar <jrmuizel@mozilla.com>
I'm also wondering that if we have ImageBitmap.transferToImageData(),
should we not also have ImageData.transferToImageBitmap()? Currently
createImageBitmap(imageData) appears to require making a copy.

On 26 June 2015 at 12:07, 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 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/
Received on Friday, 26 June 2015 11:09:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:32 UTC