- From: Noel Gordon <noel.gordon@gmail.com>
- Date: Mon, 2 Jun 2014 17:19:51 +1000
- 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]. ~noel [1] https://bugs.webkit.org/show_bug.cgi?id=54256 -- > Glenn Maynard >
Received on Monday, 2 June 2014 07:20:18 UTC