[whatwg] Proposing <canvas>.toBlob(contentType)

[Kyle Huey]

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
> >
>