- From: Rik Cabanier <cabanier@gmail.com>
- Date: Sat, 21 Mar 2015 22:45:49 -0700
- 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