W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

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

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 13 Apr 2011 18:36:05 -0400
Message-ID: <BANLkTin17+NrWzsD__bDBPCSveSf3YQ+eA@mail.gmail.com>
On Wed, Apr 13, 2011 at 6:02 PM, Kyle Huey <me at kylehuey.com> wrote:
> 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.)

FYI: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-December/029517.html

As I mentioned there, I strongly recommend this be an asynchronous
call.  Compressing images can take time, and even a small image that
only takes 300ms is enough to cause a hitch in the browser's UI.  For
example,

r = canvas.getReader();
r.onload = function(blob) { blob = r.result; }
r.readBlob();

following the pattern of FileReader (and probably borrowing from its
spec, after it stabilizes).

This allows browsers to optionally thread compression or (more likely)
run it in slices, and this API would allow Progress Events
(onprogress) to be supported later on, useful when compressing large
images (which may take several seconds).

-- 
Glenn Maynard
Received on Wednesday, 13 April 2011 15:36:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT