Mailinglist Archive: opensuse-factory (648 mails)
| < Previous | Next > |
[opensuse-factory] Re: libjpeg-turbo
- From: Fritz Elfert <fritz.elfert@xxxxxxxxxxx>
- Date: Wed, 03 Nov 2010 11:05:38 +0100
- Message-id: <4CD133F2.5040002@xxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/02/2010 10:27 PM, Cristian Morales Vega wrote:
It's exactly that.
If you read the initial comment on that bug, the poster mentions filing
the bug against the original jpeg-62b, so yes - it is 100% compatible.
BTW, that "bug" looks more like a feature request for an algorithm that
has been left out due to legal IP problems so far.
Even older CPUs provide MMX at least. Anyway, AFAIK libjpeg-turbo
figures out the CPU's capabilities at runtime and falls back from
optimized assembler code to the original C implementation.
In an environment where speed is essential (I'm using it with NoMachines
NX protocol - which can use jpeg for compressing bitmaps), libjpeg-turbo
is simply *perfect*. I don't have numbers, but my Application (OpenNX)
simply "feels" a *lot* faster when using libjpeg-turbo - especially when
working over slow connections.
Regarding stability: i'm using it for almost 2 years now and never had
any problems.
So, even if you get only 25% speed gain - it's worth the effort. For my
part, i'm really glad to see libjpeg-turbo getting into F14.
Just my 2 cent
-Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzRM+4ACgkQboM4mAMyprBqMQCdGm72iZKjZM2X4SIHAvHw0Trg
qQoAnREjkom5PDV6QXWGgjMl5MDnQb6N
=eaPt
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
Hash: SHA1
On 11/02/2010 10:27 PM, Cristian Morales Vega wrote:
Fedora 14 has been released with libjpeg-turbo
(http://libjpeg-turbo.virtualgl.org/). I see we have multiple packages
in home repos (home:Lazy_Kent, home:felfert, home:iboss32,
home:mkromer and home:prusnak)... so someone can comment about this?
Fedora sells this as a libjpeg API/ABI compatible changes that is just
faster.
It's exactly that.
From a quick look it seems to be API/ABI compatible with the
old 6.2 version that was available for years, but 11.3 already
provides the binary incompatible 8.0. What other distros do?
Also, not sure if featurewise they are 100% equivalent (see
https://bugzilla.redhat.com/show_bug.cgi?id=639672).
If you read the initial comment on that bug, the poster mentions filing
the bug against the original jpeg-62b, so yes - it is 100% compatible.
BTW, that "bug" looks more like a feature request for an algorithm that
has been left out due to legal IP problems so far.
Finally, this probably would be mostly a x86-64 improvement? Since we
target i586 for x86-32, that doesn't provides MMX/SSE support, the
speed improvement seems to be limited to a "25%" there.
Even older CPUs provide MMX at least. Anyway, AFAIK libjpeg-turbo
figures out the CPU's capabilities at runtime and falls back from
optimized assembler code to the original C implementation.
In an environment where speed is essential (I'm using it with NoMachines
NX protocol - which can use jpeg for compressing bitmaps), libjpeg-turbo
is simply *perfect*. I don't have numbers, but my Application (OpenNX)
simply "feels" a *lot* faster when using libjpeg-turbo - especially when
working over slow connections.
Regarding stability: i'm using it for almost 2 years now and never had
any problems.
So, even if you get only 25% speed gain - it's worth the effort. For my
part, i'm really glad to see libjpeg-turbo getting into F14.
Just my 2 cent
-Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzRM+4ACgkQboM4mAMyprBqMQCdGm72iZKjZM2X4SIHAvHw0Trg
qQoAnREjkom5PDV6QXWGgjMl5MDnQb6N
=eaPt
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
| < Previous | Next > |