- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 14 Mar 2011 22:21:58 -0400
(Was Daniel's reply off-list?) On Mon, Mar 14, 2011 at 9:14 PM, Jeb Boniakowski <jebjeb at gmail.com> wrote: > On Mon, Mar 14, 2011 at 9:22 PM, Daniel Cheng <dcheng at google.com> wrote: >> I'm currently 60-75% complete landing the patches for image paste support in >> Chrome.?I've chosen to expose image/png instead of a raw bitmap through >> event.clipboardData.items in Chrome as a Blob. DataTransferItem::getAsFile() That's a good starting point. I'd suggest that a different entry point is needed to support this fully. A couple things that come to mind: PNG compression is expensive; on a larger image it may take 5-10 seconds; more for more aggressive compressors. This wants an async API, so compression doesn't block and compression can be threaded. (A mechanism that can support Progress Events would make a lot of sense, too--something for much later, of course, but should at least be kept in mind, since func(successCb, errorCb) interfaces don't handle that nicely.) The same thing applies to Canvas: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029492.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030381.html (Ian's reply) Canvas users would also want to be able to load a pasted image without redundant compression and decompression steps. -- Glenn Maynard
Received on Monday, 14 March 2011 19:21:58 UTC