Re: libjpeg for F14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux