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

Re: Async Image -> ImageData conversion

From: Justin Novosad <junov@google.com>
Date: Fri, 26 Jun 2015 08:56:11 -0400
Message-ID: <CABpaAqRMrQP_9QQG-o+a8B0+--GY8rAU=T5HSjbyvAWZPQqM8A@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Ashley Gullen <ashley@scirra.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Jeff Muizelaar <jrmuizel@mozilla.com>
On Thu, Jun 25, 2015 at 4:57 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 6/24/15 1:28 PM, Ashley Gullen wrote:
>
>>
>>  Note for devices with discrete GPUs, it's possible that ImageBitmap
>> stores the decompressed image data in a GPU texture but does not have it
>> in system RAM.
>>
>
> Indeed.  This is another situation where going directly from an
> HTMLImageElement to an ImageData or Blob would make some sense, because it
> would allow the UA to avoid the GPU upload and readback, right?
>
> I'm not convinced the spec should worry about GPU uploads and readbacks.
I think the term "undue latency" is conveniently vague, which gives
implementers an interesting level of freedom to use smart heuristics and
make  implementation-specific or platform-specific or decisions. For
example, I would argue that on many platforms uploading an image to the GPU
probably does not constitute undue latency, but a readback probably does.
Under those assumptions, an implementation may decide that ImageBitmaps
should be lazily uploaded to the GPU the first time they're drawn. That way
the GPU can be short-circuited when appropriate. Also, the spec requires
that ImageBitmaps be *drawn* without undue latency, it does not require
that converting to a Blob or an ImageData be lightning fast.  Anyways, my
point is that implementers have enough wiggle room to do the right thing
even without direct methods on <img>.


>
> -Boris
>
>
Received on Friday, 26 June 2015 12:56:39 UTC

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