Hi,
SSE and friends are arch. specific and according to the feature list
the upstream is displaying, I don't think it would offer any other
benefits for the other archs.
There is one strong point that libjpeg-{6b, 8ab} inherited since it's
been there for a lof time: a *defacto* standard for JPEG
compression/decompression that has been heavily depolyed, used and
tested code for various application/, thoughtout the time, for more
than a decade! I think that's important and would enable it to keep
its place in the destribtion.
libjpeg-6b is at production level code, and it actually offers a
couple of ways to accelerate JPEG decoding by turning on the IDCT
level decimation (basically for free resize) and enabling YUV raw
decodes.
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? That way ijg can test for any
regressions using their conformance tests.
Regards,
-Ilyes Gouta
On Tue, May 25, 2010 at 3:23 PM, Adam Goode <a...@spicenitz.org> wrote:
> On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
>> Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
>> (For the primary architectures anyway).
>>
>
> I think this is a great idea, libjpeg is the bottleneck for a lot of my
> code.
>
> One issue: are there C fallbacks for all the arch-specific code? It
> would be great if secondary architectures could just use libjpeg-turbo
> as well.
>
>
> Adam
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
