W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

Re: [whatwg] Canvas image to blob/dataurl within Worker

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 22 Mar 2015 00:16:53 -0700
Message-ID: <CAGN7qDBTNsVOVZpe3sBUyGMO9GEbQ1u+C8bbiBP3jnpeaqaWaQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: WHATWG <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Jake Archibald <jaffathecake@gmail.com>, Ashley Gullen <ashley@scirra.com>
On Sat, Mar 21, 2015 at 11:02 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Sun, Mar 22, 2015 at 6:45 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan <robert@ocallahan.org>
>> wrote:
>>
>> > On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier <cabanier@gmail.com>
>> wrote:
>> >
>> >> Justin is worried that in order to make this asynchronous, Chrome has
>> to
>> >> create a snapshot of the canvas bits which is slow if it resides on the
>> >> GPU.
>> >> Of course, his workaround to use getImageData is just as slow since it
>> has
>> >> to do the same operation.
>> >>
>> >
>> > One of the advantages of having a native async toBlob API is that the
>> > browser can asynchronously read back from GPU memory (when the graphics
>> API
>> > permits this --- D3D11 does, at least). Gecko currently doesn't take
>> > advantage of this, however.
>> >
>>
>> You would need a copy in GPU memory first to do the async readback on.
>>
>
> Not necessarily.
>
>
>> There are many scenarios (ie fullscreen hidi canvas) where this might fill
>> the GPU's memory.
>>
>
> Unlikely in practice.
>

Hopefully Justing can chime in on this. Google maps in particular taxes the
GPU a lot.
If Chrome has to reserve enough space for another backbuffer, this will
certainly make rendering of complex scenes slower.


> > To alleviate this, I have 2 proposals:
>> >> - After calling toBlob, the canvas is read-only until the promise is
>> >> fulfilled
>> >> - If the user changes the canvas after calling toBlob, the promise is
>> >> cancelled.
>> >>
>> >> Maybe we should only allow 1 outstanding toBlob per canvas element too.
>> >>
>> >
>> > I don't think we should impose any of these restrictions. They're not
>> > necessary.
>> >
>>
>> How else would you avoid making a copy?
>>
>
> It depends on lots of variables, but there are certainly scenarios when
> you can do async readback without making a copy.
>
> Even if you have to make a copy in GPU memory, that's not a big problem
> most of the time, not compared to doing a synchronous readback.
>
> Rob
> --
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> owohooo
> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> oioso
> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> owohooo
> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
> ooofo
> otohoeo ofoioroeo ooofo ohoeololo.
>
Received on Sunday, 22 March 2015 07:17:19 UTC

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