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

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

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 29 May 2014 14:17:35 -0500
Message-ID: <CABirCh9eYeOU92X_Cqvs9y6EBfijHB8BbYvnDao3HaYtruXMag@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Noel Gordon <noel.gordon@gmail.com>
On Thu, May 29, 2014 at 10:29 AM, Rik Cabanier <cabanier@gmail.com
<javascript:_e(%7B%7D,'cvml','cabanier@gmail.com');>> wrote:

> If performance is good, why would this not be acceptable?
>

 I don't know why we'd provide an API to compress PNGs, then tell people to
use a script reimplementation if they want to set a common option.

As far as performance, I'm not sure about PNG, but there's no way that a JS
compressor would compete with native for JPEG.  Assembly (MMX, SSE)
optimization gives a significant performance improvement over C, so I doubt
JS will ever be in the running.  (
http://www.libjpeg-turbo.org/About/Performance)


> It seems that this would be a fragmented solution as file formats and
> features would be added at different stages to browser engines. Would there
> be a way to feature test that the optional arguments are supported?
>

No more than any other new feature.  I don't know if feature testing for
dictionary arguments has been solved yet (it's come up before), but if not
that's something that needs to be figured out in general.

-- 
Glenn Maynard



-- 
Glenn Maynard
Received on Thursday, 29 May 2014 19:18:05 UTC

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