On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit <t...@tillschneidereit.net> wrote: > On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto <gsve...@mozilla.com> wrote: >> On 10/10/2013 02:36, Zack Weinberg wrote: >>> >>> In that vein, I think we should take a hard look at the image decoders. >>> Not only is that a significant chunk of attack surface, it is a place >>> where it's hard to innovate; image format after image format has died on >>> the vine because it wasn't *enough* of an improvement to justify the >>> additional glob of compiled code. Web-deliverable JS image decoders >>> could open that up. >> >> >> Considering the performance profile of some of our low-end platforms (most >> Firefox OS devices, low-end Android devices too) I don't think that would be >> a good idea right now. Image decoding speed has a very measurable impact >> there during page/application startup. The difference between vectorized >> code-paths (NEON on ARM) and plain C is quite significant so moving it to JS >> (even asm.js-enabled JS) would probably lead to pretty bad performance >> regressions. > > Note that we'll have SIMD support in JS in the not-too-distant > future[1]. Once asm.js supports it, this idea might be more practical. > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=904913
I'm not sure. Things like this seem like really good ideas: http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx Obviously, I am linking to somewhat of an advertisement of a competitor but the idea sounds great, especially the bit about significantly lower memory usage. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
