- From: Kyle Huey <me@kylehuey.com>
- Date: Wed, 13 Apr 2011 23:42:56 -0700
It doesn't necessarily imply that the encoding is synchronous. The problem here is that Blob.size is broken. The point of the File API is to do reads asynchronously without blocking the main thread on something slow. This is why the only way to get at a Blob's contents is through something like FileReader which is asynchronous and event driven. Blob.size goes totally against all of this. I wonder if it's possible to remove size entirely? Jonas? It's been shipped in Firefox since 3.5 though, and Chrome since some version from quite a while ago, so I fear it's here to stay. Assuming that Blob.size is here to stay, web developers are just going to have to cope with the fact that it's broken and causes synchronous slow things to happen. I believe (though I haven't verified) that in Gecko we avoid statting a file on the disk that backs a Blob until Blob.size is called (or somebody passes it to a FileReader and we can touch the disk asynchronously, etc). In this case the UA could optimize, for example, by encoding on a background thread and simply blocking inside a size call when the encoding has not completed. The main drawback of making it asynchronous is that (AIUI, please correct me if I'm wrong) everything else about the canvas element and the 2d rendering context is synchronous. This adds cognitive overhead both for developers and actual code complexity for implementations. I'll assert, however, that the "behind the scenes" complexities of presenting an asynchronous API for getting a blob and presenting a synchronous API that performs the optimization above are the same. In particular, in both cases the UA must handle:modifications to the canvas after the Blob Getting API is called. Given this, and that providing an asynchronous API to get an object that is supposed to be inherently asynchronous seems silly, I would prefer the synchronous version here. - Kyle On Wed, Apr 13, 2011 at 3:37 PM, David Levin <levin at chromium.org> wrote: > Shouldn't this api be async? > > Returning a blob means that the size is available which implies a sync > operation. > > dave > > On Wed, Apr 13, 2011 at 3:02 PM, Kyle Huey <me at kylehuey.com> wrote: > > Hello All, > > > > Gecko 2.0 ships with a non-standard method on <canvas> named > > mozGetAsFile(contentType, fileName). We added this for internal use in > our > > UI. It retrieves the contents of the canvas as a File object (at the > time > > Gecko did not supports Blobs) encoded in the contentType according to the > > same rules toDataURL uses. > > > > I propose adding a toBlob(contentType) method to the canvas element in > the > > style of toDataURL. This would greatly increase the options available to > > developers for extracting data from a canvas element (a Blob can be saved > to > > disk, XHRed, etc.) > > > > - Kyle > > >
Received on Wednesday, 13 April 2011 23:42:56 UTC