[whatwg] Expose event.dataTransfer.files accessor to allow file drag and drop

[Noel Gordon]

> PROPOSAL
>
> When the user drags-and-drops files onto a web page, we should expose
> those files to the page via a "files" accessor on the dataTransfer
> property of the event object.  This feature is consistent with HTML
> 5's security model for drag and drop.

I wasn't clear on this part -- how is the proposal consistent with the HTML5
drag drop security model?

~noel

[whatwg] Proposal: toDataURL “image/png” compression control

[Noel Gordon]

.toDataURL supports an optional quality argument for the
“image/jpeg” mime type to control image compression. Developers have no
control over “image/png” compression.

“image/png” is a lossless image compression format and the proposal is to
allow developers some control over the compression process. For example, a
developer might request maximum compression once their art work is complete
to minimize the encoded image size for transmission or storage. Encoding
speed might be more important while creating the work, and less compression
(faster encoding) could be requested in that case.

An optional toDataURL parameter on [0.0 ... 1.0], similar to the optional
quality argument used for "image/jpeg", could be defined for “image/png” to
control compression:

   .toDataURL(“image/png”, [compression-control-value]);

The default value, and how the browser controls the image encoder to gain
more compression with increasing values, would be internal implementation
details of the browser.

~noel

Re: [whatwg] Proposal: toDataURL “image/png” compression control

[Noel Gordon]

On Sun, Jun 1, 2014 at 8:58 AM, Glenn Maynard  wrote:

>
> But again, image decoding *can't* be done efficiently in script:
> platform-independent code with performance competitive with native SIMD
> assembly is a thing of myth.  (People have been trying unsuccessfully to do
> that since day one of MMX, so it's irrelevant until the day it actually
> happens.) Anyhow, I think I'll stop helping to derail this thread and
> return to the subject.
>

I believe that a spec-conforming  implementation must support PNG,
so a PNG encoder/decoder is required. If others want to replace their
native libs (libpng, libjpeg_turbo, and so on) with JS implementations of
same, well that's up to them. Won't be happening in Chrome anytime soon due
to dependent factors: speed, memory use, and security, come to mind. But
agree, let's return to the subject :)

Noel, if you're still around, I'd suggest fleshing out your suggestion by
> providing some real-world benchmarks that compare the PNG compression rates
> against the relative time it takes to compress.  If spending 10x the
> compression time gains you a 50% improvement in compression, that's a lot
> more compelling than if it only gains you 10%.  I don't know what the
> numbers are myself.
>

For the test case attached, and https://codereview.chromium.org/290893002

compression 0.0, time 0.230500 ms, toDataURL length 2122
compression 0.1, time 0.209900 ms, toDataURL length 1854
compression 0.2, time 0.215200 ms, toDataURL length 1850
compression 0.3, time 0.231100 ms, toDataURL length 1774
compression 0.4, time 0.518100 ms, toDataURL length 1498
compression 0.5, time 0.532000 ms, toDataURL length 1494
compression 0.6, time 0.612600 ms, toDataURL length 1474
compression 0.7, time 0.727750 ms, toDataURL length 1470
compression 0.8, time 1.511150 ms, toDataURL length 1334
compression 0.9, time 3.138100 ms, toDataURL length 1298
compression 1.0, time 3.182050 ms, toDataURL length 1298

I'd be careful using compression rates / encoding times as figures of merit
though -- those depend on the source material (the input to the PNG
encoder). Given incompressible source material, PNG encoding cannot gain
compression at all.

The question (for me) is whether developers should be allowed to control
the compression using a pre-existing API. The browser has a default
compression value, it's a compromise that ... surprise, surprise ...
doesn't always meet developer expectations [1].

~noel

[1] https://bugs.webkit.org/show_bug.cgi?id=54256

-- 
> Glenn Maynard
>