W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Rich Paste & DataTransfer / DataTransferItems API

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 14 Mar 2011 22:21:58 -0400
Message-ID: <AANLkTinp6gAZjBabqWpqEXU8NFEbRsP67zPjjqRX2XX4@mail.gmail.com>
(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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC