- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 29 May 2014 13:35:32 -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 1:33 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > > 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. > Here's a link to an experiment: http://multimedia.cx/eggs/playing-with-emscripten-and-asm-js/ > 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:35:56 UTC