[whatwg] HTML Canvas Element getBlob

[Charles Pritchard]

On 12/27/2010 3:29 PM, Glenn Maynard wrote:
> On Mon, Dec 27, 2010 at 5:31 PM, Charles Pritchard<chuck at jumis.com>  wrote:
>> Nothing in Canvas is current asynchronous. Nor is there precedent, beyond
>> string serialization, in the File API, for compression/checksum/stream
>> processing.
> Not sure what you mean by the latter.  Everything in both the File API
> and the filesystem API has an async interface.
With async, I'm referring to Canvas.

With the File API, readAsXXX is as far as things have gotten.
There's no precedent, yet, for deflate compression, sha1/md5 checksum, etc.

>> 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.
> A synchronous API doesn't need to wait for an asynchronous one (no pun
> intended); most async interfaces have synchronous counterparts.  But,
> please keep the async case in mind.  Seeing async compression
> dismissed out-of-hand in
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024691.html
> was a bit worrisome.
You may not want to build an entire Blob in memory: most compression 
works on a sliding window.

Using an ArrayBuffer, with onprogress events would be more flexible (and 
verbose)
than using a getAsyncBlob method.

ArrayBuffer has a similar use for XHR responses in memory limited areas.

responseBlob is still being hashed out, it seems.