Re: [whatwg] Canvas image to blob/dataurl within Worker
On Sun, Mar 22, 2015 at 6:45 PM, Rik Cabanier wrote: > On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan > wrote: > > > On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier > 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. > Not necessarily. > There are many scenarios (ie fullscreen hidi canvas) where this might fill > the GPU's memory. > Unlikely in practice. > 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? > It depends on lots of variables, but there are certainly scenarios when you can do async readback without making a copy. Even if you have to make a copy in GPU memory, that's not a big problem most of the time, not compared to doing a synchronous readback. 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 wrote: > On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier 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?
Re: [whatwg] Canvas image to blob/dataurl within Worker
On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier 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 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 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 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 wrote: >> >> > On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier >> 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 4:19 AM, Jake Archibald 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 wrote: > >> On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier 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 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 wrote: > > > On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier > 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 wrote: > On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier 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 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.
