[whatwg] Rich Paste & DataTransfer / DataTransferItems API

I probably sent it with the wrong from: address.

On Mon, Mar 14, 2011 at 19:21, Glenn Maynard <glenn at zewt.org> wrote:

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

Is there an alternate bitmap format that's likely to be widely supported
across different browsers? I picked PNG since if the compression proves to
be expensive, we can simply try less hard to compress the data (at the
extreme end, we don't compress it at all and it basically just becomes a
bitmap container).

It would definitely be nice if you didn't need to know the length of the
data when creating a Blob.

Daniel

Received on Monday, 14 March 2011 19:47:26 UTC