Re: [whatwg] Canvas image to blob/dataurl within Worker
On Sat, Mar 21, 2015 at 4:19 AM, Jake Archibald jaffathec...@gmail.com wrote: I'd rather we did that by introducing promises to HTMLCanvasElement. Returning a promise from toBlob is easy, making the callback arg optional by checking the type of the first arg is hacky but possible (and is done in js libs). The spec (if there is one?) should be updated to return a promise and leave out the callback: promise canvas.toBlob(optional type, optional encoderOptions); Mozilla would keep their existing implementation around and the IDL logic would automatically pick the right call. On Sat, 21 Mar 2015 10:56 Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier caban...@gmail.com wrote: Ah, OK. I thought we were changing it for both cases. This will cause a lot of confusion... If we want to keep HTMLCanvasElement and WorkerCanvas in sync, we can.
Re: [whatwg] Canvas image to blob/dataurl within Worker
Is everyone here aware that currently Google have stated they do not plan to implement toBlob?: https://code.google.com/p/chromium/issues/detail?id=67587 IMO this is the wrong call. We should be favouring blobs over data URLs since they are more efficient (no size bloat, can be requested async like other network resources, no need to copy round very large strings). On 21 March 2015 at 11:19, Jake Archibald jaffathec...@gmail.com wrote: I'd rather we did that by introducing promises to HTMLCanvasElement. Returning a promise from toBlob is easy, making the callback arg optional by checking the type of the first arg is hacky but possible (and is done in js libs). On Sat, 21 Mar 2015 10:56 Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier caban...@gmail.com wrote: Ah, OK. I thought we were changing it for both cases. This will cause a lot of confusion... If we want to keep HTMLCanvasElement and WorkerCanvas in sync, we can. 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 ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] Canvas image to blob/dataurl within Worker
On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier caban...@gmail.com wrote: Ah, OK. I thought we were changing it for both cases. This will cause a lot of confusion... If we want to keep HTMLCanvasElement and WorkerCanvas in sync, we can. 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 ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] Canvas image to blob/dataurl within Worker
I'd rather we did that by introducing promises to HTMLCanvasElement. Returning a promise from toBlob is easy, making the callback arg optional by checking the type of the first arg is hacky but possible (and is done in js libs). On Sat, 21 Mar 2015 10:56 Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier caban...@gmail.com wrote: Ah, OK. I thought we were changing it for both cases. This will cause a lot of confusion... If we want to keep HTMLCanvasElement and WorkerCanvas in sync, we can. 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 ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] Canvas image to blob/dataurl within Worker
On Sat, Mar 21, 2015 at 6:21 AM, Ashley Gullen ash...@scirra.com wrote: Is everyone here aware that currently Google have stated they do not plan to implement toBlob?: https://code.google.com/p/chromium/issues/detail?id=67587 IMO this is the wrong call. We should be favouring blobs over data URLs since they are more efficient (no size bloat, can be requested async like other network resources, no need to copy round very large strings). 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. 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 made a small code example of toBlob here: http://codepen.io/adobe/full/raoZdQ/ It works smoothly on my mac and pc laptop, but really janky on my PC desktop. On 21 March 2015 at 11:19, Jake Archibald jaffathec...@gmail.com wrote: I'd rather we did that by introducing promises to HTMLCanvasElement. Returning a promise from toBlob is easy, making the callback arg optional by checking the type of the first arg is hacky but possible (and is done in js libs). On Sat, 21 Mar 2015 10:56 Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier caban...@gmail.com wrote: Ah, OK. I thought we were changing it for both cases. This will cause a lot of confusion... If we want to keep HTMLCanvasElement and WorkerCanvas in sync, we can. 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 ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] Canvas image to blob/dataurl within Worker
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?
