libjpeg for F14

[Ilyes Gouta]

Hi,

A merge is the most appropriate here. After all libjpeg-turbo just
offers a set of x86 specific SSE/MMX routines such as IDCT (maybe
huffman, but I didn't check that) that would be easily plugged into
ijg, but doesn't change the foundations (architecture and exposed
public API) of libjpeg.

Also, one has to think about the applications that depend on it: what
if they break and/or require changes.

-Ilyes Gouta

On Wed, May 26, 2010 at 1:45 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Ilyes Gouta wrote:
>> 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.
>
> This kind of arguments doesn't really make sense for Fedora. We should ship
> the best implementation, not the most "tried and true" one. Fedora is about
> advancing Free Software, not being conservative. If you see any concrete
> issues with libjpeg-turbo, do point them out. If not, we shouldn't refuse it
> just because it's not the same old stuff.
>
> Something which is IMHO more important to consider is whether libjpeg-turbo
> is missing any improvements which are in the current IJG codebase, e.g. new
> APIs apps may start relying on at some point. (In that case, we need to
> either decide which to ship or ship both.)
>
>        Kevin Kofler
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>