Good point - it makes sense to have ImageBitmap as the "hub" of all
conversion.

I've drafted a new spec which instead proposes ImageBitmap.toBlob() and
ImageBitmap.toImageData():
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html

This should cover all conversion cases asynchronously.



On 23 June 2015 at 20:34, Justin Novosad <ju...@google.com> wrote:

> Based on feedback received from web developers, new APIs that move image
> data around should also strive to eliminate intermediate copies of the
> image data to avoid memory bloat. I think your proposal achieves that, but
> I think memory footprint reduction could be a stated objective of the
> proposal. For example, the current solution of using a canvas forces the
> creation of an intermediate copy (the canvas).
>
> Also, to avoid the multiplication of APIs for moving image data between
> various representations, I would like to suggest an alternative: using the
> ImageBitmap interface as a hub. The creation of ImageBitmaps is already
> asynchronous (createImageBitmap returns a promise), and it has overloads
> for acquiring images from img, video, canvas, url, blob, imagedata. All
> that is missing are a few methods for getting data directly out of an
> ImageBitmap. So I think adding toBlob and toImageData (both async) to
> ImageBitmap is a more succinct proposal that would address your use cases,
> and many additional ones at the same time.
>

Reply via email to