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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
