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 <ann...@annevk.nl> wrote: > On Thu, Jun 25, 2015 at 1:57 PM, Boris Zbarsky <bzbar...@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/ >