[Interest] libjpeg vs. libjpeg-turbo/mozjpeg

[René J.V. Bertin]

On Saturday May 23 2015 19:06:47 Allan Sandfeld Jensen wrote:

>We don't rely on them as far as I know, but the new compression formats might 
>be supported automatically by libjpeg and thus by Qt linked against libjpeg-
>v9,

Yes, even after tweaking the libjpeg-turbo dylib so that it has the correct name and compatibility version for the dynamic loader to find and accept it, code linked against libjpeg v9 won't work. v9 didn't just add a couple of features.

>but if no one are using them because they are non standard, losing them 
>shouldn't be a problem.

And I suppose you're not exporting any of the libjpeg symbols, so a clash shouldn't occur when the user links to a different version, I presume.

>
>The bug for replacing lbjpeg with libjpeg-turbo is 
>https://bugreports.qt.io/browse/QTBUG-40091 - Feel free to take it over :)

Funny how that focusses on a performance difference which is apparently not due to using libjpeg-turbo vs. the regular version.
I started tweaking my own MacPorts installation when I saw LibVNCServer suggest I could get better performance with libjpeg-turbo. I thought that VNC would be an area where you'd see a 2-4x decoding gain, but I didn't notice anything that was worth the hassle I went through to get the two libjpegs co-installed under MacPorts. Ditto with the largest jpgs I could find and comparing using a lean and mean viewer like xv .
Apparently the few tests I did where not decoding-constrained even on a 4yo 2.7Ghz i7 ...

R.