W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2014

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

From: Noel Gordon <noel.gordon@gmail.com>
Date: Mon, 2 Jun 2014 17:19:51 +1000
Message-ID: <CAN8OJAA17nMAZmP0oqYF64yvZDYXDx52d=DMENm9-TsewC8R-w@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Justin Novosad <junov@google.com>, whatwg <whatwg@lists.whatwg.org>, Rik Cabanier <cabanier@gmail.com>, Robert O'Callahan <robert@ocallahan.org>, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
On Sun, Jun 1, 2014 at 8:58 AM, Glenn Maynard <glenn@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].


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

> Glenn Maynard
Received on Monday, 2 June 2014 07:20:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC