- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 27 Dec 2010 18:29:02 -0500
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