- From: Ashley Gullen <ashley@scirra.com>
- Date: Fri, 26 Jun 2015 12:08:37 +0100
- 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>
- Message-ID: <CAABs73hTqKPuPOzmasPG9+NKGY5nG_epaJtEMCsJ6j+dGuk7zg@mail.gmail.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