libjpeg vs. libjpeg-turbo

[Ryan Schmidt]

On May 24, 2015, at 8:52 PM, Lawrence Velázquez wrote:

> On May 24, 2015, at 9:00 PM, Ryan Schmidt wrote:
> 
>> On May 24, 2015, at 9:43 AM, René J.V. Bertin wrote:
>> 
>>> but I think I won't. I'm just not convinced that recent/fast machines will see any measurable gain from the whole exercise.
>> 
>> ...which exercise?
> 
> Replacing libjpeg with libjpeg-turbo. I think this point is off-topic, as this discussion is primarily about maintainability and not performance.

...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.


>>> The issue is moot if port:jpeg is discontinued. If it's not, it's special in that there are 3 alternatives that each provide one of two ABI versions, and only port:jpeg being unambiguous about what version it provides.
>>> Anyway, I think it's something that can be decided upon on a case-by-case basis. There is precedence; gstreamer comes to mind.
>> 
>> gstreamer1 and gstreamer010 are named after the project version number, not any included library's version number. There are many many ports named after the project version number
> 
> Yes, and nearly all of them are a significant pain to maintain. This is one reason I'm paring back our Python selection. (GCC is on deck.) I would like to avoid creating more versioning if we can help it.

There are situations where it is helpful. I don't think the jpeg libraries qualify.


>> But if we don't let the user choose between libjpeg-turbo and mozjpeg, how then is a user who wants to use mozjpeg going to do that? Imagine I want to compress a bunch of images using ImageMagick, and I want them to be as small as possible, and I don't care if it takes longer to encode them. That's what mozjpeg is for. I had envisioned that in this situation, I would force-deactivate libjpeg-turbo, activate mozjpeg, and then use ImageMagick as planned. Then when I was done I would deactivate mozjpeg and re-activate libjpeg-turbo. Though thinking about it now, I guess for that use case it wouldn't really matter if ImageMagick declared its dependency on path:lib/libjpeg.dylib:libjpeg-turbo or just port:libjpeg-turbo; either way, libjpeg-turbo will have to be forcibly deactivated.
> 
> It doesn't matter for that specific case, but a user who for some reason wanted to always use mozjpeg could still install it up front and let all dependencies pick it up.

Right, and specifically because mozjpeg is designed to be slower, and because the libjpeg-turbo people say mozjpeg is therefore not suitable as a general purpose system jpeg library, maybe it would be right for us to prevent users from doing that.