libjpeg vs. libjpeg-turbo

[René J.V. Bertin]

On Monday May 25 2015 05:07:37 Mihai Moldovan wrote:

>> ...I assumed it was also about performance. If we object to changes IJG is making to jpeg, we can also just stop updating jpeg past 9, or we can downgrade it to 8.

++

>For me, it also is. I'm dependent upon a fast JPEG decompressor for another
>application I'm part of upstream. I do not particularly care what the default
>JPEG port is in MacPorts as long as there is a choice for being able to switch
>to libjpeg-turbo (i.e., a path-based dependency), but I very much prefer

Exactly; even if you can actually show a significant benefit to libjpeg-turbo in your application that doesn't mean that benefit exists in enough ports across the board to warrant forcing all ports to be rebuilt against it. In that case there would just be the need for something like a port_select mechanism to let libjpeg.dylib point to the library of choice, and make the appropriate headers available. In turn, installed ports will continue to function after switching the selected jpeg library, even if port:jpeg continues to provide v9.

>libjpeg-turbo for speed and compatibility reasons (again, Linux distributions
>switched to libjpeg-turbo and a cross-platform application benefits from the
>same toolchain even on the other platforms.)

If we assume that libjpeg-turbo is indeed fully ABI compatible with libjpeg the cross-platform toolchain argument is moot.
As to Linux distros having switched:
- not all apparently; gwenview has a commit to allow it to build against libjpeg v9 that was done by someone @gentoo
- how long ago was that done? Also, Linux tends to address a much wider range of hardware (both in age and specs) than OS X does. It'd be understandable that they stick to their choice as long as it doesn't become a disadvantage compared to the existing alternatives.

Heh. That reminds me of an insight from Evolution Theory that fits my views on software updating perfectly: Darwin shouldn't have used the term "survival of the fittest", but "non-survival of the non-fittest" :)

R