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

[Noel Gordon]

On Sun, Jun 1, 2014 at 8:58 AM, Glenn Maynard gl...@zewt.org 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 canvas 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

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

[Noel Gordon]

canvas.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:

   canvas.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

[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