[whatwg] HTML Canvas Element getBlob

Charles Pritchard chuck at jumis.com
Mon Dec 27 14:31:06 PST 2010


On 12/27/2010 2:20 PM, Glenn Maynard wrote:
> On Mon, Dec 27, 2010 at 4:32 PM, Charles Pritchard<chuck at jumis.com>  wrote:
>> I'd like to see Blob output added to the HTML Canvas element :
>>
>> Blob getBlob(in optional DOMString type, in any... args);
> This should be asynchronous, eg:
>
> void getBlobAsync(in Function oncomplete, in Function onerror, in
> optional DOMString type, in any... args);
>
> where oncomplete is called with the resulting Blob after compression finishes.
>
> Compressing a large canvas can take some time, especially at higher
> compression levels--saving a fairly small, 1000x1000 image to PNG in
> Photoshop takes almost five seconds on my system.  A UA may also queue
> canvas operations if the canvas isn't visible; it sometimes seems like
> Chrome is doing this, though I'm not sure.  This gives browsers the
> option of pushing all of the queue flushing and compression into the
> background.
>
> This shouldn't be required; a UA should be permitted to run the
> compression synchronously.  There should also be a way to abort
> compression, since any asynchronous operation should be cancellable.
> (An event-based interface like FileReader's is probably more
> appropriate.)

Nothing in Canvas is current asynchronous. Nor is there precedent, beyond
string serialization, in the File API, for compression/checksum/stream 
processing.

Such work is certainly welcome, but I don't think it should stand in the 
way of incremental improvement.

Async image compression can currently be accomplished via Web Workers 
and ImageData (though slow, yes).

Synchronous getBlob support would take minimal time, in code bases and 
specs processes,
and has the very immediate benefit of ridding the DOM of nasty data uri 
strings.






More information about the whatwg mailing list