On Wed, Feb 10, 2016 at 2:38 PM, Ashley Gullen <ash...@scirra.com> wrote:

> ImageBitmap is not useful for getting the data from: it still requires
> synchronous use of a canvas to turn in to an ImageData. I would encourage
> browser vendors to look at my spec proposal to avoid this:
> http://wicg.github.io/img-conversion/

Yes, that is on our radar. We need APIs to move image data without making
so many intermediate copies in RAM. AFAIK, this appears to be a real
problem for image manipulation apps, which tend to quickly run out of RAM.
ImageBitmap partially addresses this, but it does little for apps that need
to do direct image data manipulation.

ImageData.toBlob is low hanging fruit IMHO.

For the create method, I'm not sure. I think a smaller API surface that
would provide the same functionality is a transfer method that transfers an
ImageBitmap into an ImageData. This would neuter the image bitmap, it would
throw an exception if the ImageBitmap is tainted. To get lossless
unpremultiplied image data you would leverage the imagebitmap options.

> On 10 February 2016 at 18:29, Gregg Tavares <g...@chromium.org> wrote:
> > Is there a reason in the proposal many of the options default to
> > "implementation specific behavior"?
> >
> > If the point of ImageBitmap is to get the data (use Image if you don't
> > care), then it seems like having any "implementation defined" options,
> > especially as the default, is just asking for lurking bugs in websites
> >

Reply via email to