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

Re: Subject=Re: Async Image -> ImageData conversion

From: Ashley Gullen <ashley@scirra.com>
Date: Wed, 24 Jun 2015 13:37:53 +0100
Message-ID: <CAABs73gDP1sSJ42u91A_KsttP6QbhY02hd8ZUwKkBA3PhYdo-g@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
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 <junov@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.
>
Received on Wednesday, 24 June 2015 12:38:22 UTC

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