- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Sun, 22 Mar 2015 09:44:12 +1300
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Ian Hickson <ian@hixie.ch>, Ashley Gullen <ashley@scirra.com>
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. > 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. 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 Saturday, 21 March 2015 20:44:39 UTC