- From: Jeb Boniakowski <jebjeb@gmail.com>
- Date: Tue, 15 Mar 2011 00:15:16 -0300
Glenn's point is a good one and the problem isn't whether the bitmap will be supported across the browsers, its whether the bitmap will make it to the system pasteboard in the first place (assuming its being put there from a source other than the browser. While the browser could push pngs or whatever, imagine how frustrating it would be to users if you could paste after copying from a browser window but not from a random desktop app). At least on OS X, it looks like applications make sure to make copied images available in tiff and pict formats, presumably so every drag/paste target doesn't have to support converting from every image format (also IIRC tiff and pict are pretty simple 'buffer of pixels w/ a header' formats, right?) So the AFAICT possibilities are: - Do what Glenn said and design an async API, which is more complicated for the spec, implementors, and users - Cheat. e.g. monitor the system clipboard in a background thread and begin converting anything matching the system's image formats in the background/when usage is low, and then only block if you don't convert in time. This is...gross, but would be simple to use. jeb. On Mon, Mar 14, 2011 at 11:47 PM, Daniel Cheng <dcheng at chromium.org> wrote: > 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 20:15:16 UTC