On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan <rob...@ocallahan.org>

> On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier <caban...@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?

Reply via email to