- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 29 May 2014 13:33:54 -0700
- 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