On Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote: > On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote: > > How about this: since libjpeg is picking momentum and there are > > actually people updating the code base, why not push for a > > libjpeg-turbo merge into the original ijg's code and get Fedora to > > rebase on that unique source instead? > > The problem, as I said before, is that the libjpeg upstream is not > being developed in an open manner. This is pretty big issue. > I've emailed Adam Tkac to bring his attention to this thread (he's > involved with libjpeg-turbo) and hopefully he'll bring some more up to > date information about this matter. Sorry for late response, this mail got lost in my queue. libjpeg-turbo is a fork of the original libjpeg-6b release created and maintained by VirtualGL and TigerVNC developers. Main focus is on performance and API+ABI compatibility with libjpeg. Although libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. When SSE is used then libjpeg and libjpeg-turbo performance is simply incomparable. And there are still number of areas for optimizations, for example on we are currently using only half of SSE registers on 64bit platforms. About the merge of this code with the original ijg's code. Yes, I must admit it is possible but personally I don't like it much. In my opinion libjpeg-turbo is far more ahead than libjpeg so it's easier for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not able to find CVS/SVN/git repository of the libjpeg code. In my opinion if will be great benefit for Fedora to simply replace libjpeg by libjpeg-turbo. It works fine on secondary architectures and if processor doesn't support MMX/SSE then it falls back to non-ASM code (which is still faster than libjpeg code, as I wrote above). Btw this library is used since Fedora 11 in tigervnc package for JPEG compression/decompression and it works without any problem on all supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x). So, if I summarize pros and cons for libjpeg-turbo: +: _really_ faster than libjpeg more portable more open than IJG code API/ABI compatible with libjpeg (AFAIK) works on all platforms (not only on SSE capable platforms) -: not developed by IJG :) I'm going to create a Fedora feature for this task. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
