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