On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> 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?