- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 27 Dec 2010 14:31:06 -0800
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.
Received on Monday, 27 December 2010 14:31:06 UTC