W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

[whatwg] HTML Canvas Element getBlob

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 27 Dec 2010 18:29:02 -0500
Message-ID: <AANLkTimqOE0kSm9csWKsu564Yd3NCA2=qibNoJb3K1zC@mail.gmail.com>
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.

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

Implementing a PNG compressor in Javascript isn't a serious option.

Workers would be reasonable for this if it was possible to do
off-screen canvas work in a web worker.  It's unfortunate that it's
not--to me that's the single most obvious use of worker threads (image
loads and decompression; image blits, resizing, rotation; canvas
compression; etc).  I hope this sort of thing is just on hold while
the core Web Worker spec is worked out.

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

-- 
Glenn Maynard
Received on Monday, 27 December 2010 15:29:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:02 UTC