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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 29 May 2014 13:33:54 -0700
Message-ID: <CAGN7qDDvzVEOzXNtw5SiJAR7ALaJsuSZ6dnXcNroybFiaqwf_Q@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: whatwg <whatwg@lists.whatwg.org>, Noel Gordon <noel.gordon@gmail.com>
On Thu, May 29, 2014 at 12:17 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Thu, May 29, 2014 at 10:29 AM, Rik Cabanier <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)

MMX, SSE is being addressed using asm.js.
We're also just dealing with screenshots here. I doubt people are going to
do toDataURL at 60fps.

>> 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.
Received on Thursday, 29 May 2014 20:34:20 UTC

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