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: Sat, 21 Mar 2015 22:45:49 -0700
Message-ID: <CAGN7qDC=hcgDRqvHGNc6=2ni+rp8rSi0oqEO+VBB3CbMAa14oA@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Ian Hickson <ian@hixie.ch>, Ashley Gullen <ashley@scirra.com>
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.
There are many scenarios (ie fullscreen hidi canvas) where this might fill
the GPU's memory.


> 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?
Received on Sunday, 22 March 2015 05:46:15 UTC

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