W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2016

Re: [whatwg] Reviving ImageBitmap options: Intend to spec and implement

From: Ashley Gullen <ashley@scirra.com>
Date: Thu, 11 Feb 2016 16:40:51 +0000
Message-ID: <CAABs73j+F2J2vH4fewyZC8Rh3+qKWzoJq+PZ1-F-U2jd7or=BA@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Gregg Tavares <gman@chromium.org>
It's an interesting option to create a non-premultiplied ImageBitmap and
convert on to an ImageData. However I was under the impression the point of
ImageBitmap was to be drawn "without undue latency", which browsers could
interpret as a pre-allocated GPU texture. Doesn't this make it difficult to
use ImageBitmap as a conversion intermediary? If GPU readback is involved,
that could be slow, and if it's in RAM, isn't it storing the image twice?
This point was one of the motivating factors in writing a spec that could
do things like a direct asynchronous Blob -> ImageData.




On 10 February 2016 at 20:27, Justin Novosad <junov@google.com> wrote:

> On Wed, Feb 10, 2016 at 2:38 PM, Ashley Gullen <ashley@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 <gman@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
>> >
>>
>
>
Received on Thursday, 11 February 2016 16:41:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:37 UTC