Nice. Anyone know if the ARM distro's are using this by default? Seems like it would help quite a bit on ARM platforms with NEON... sadly, the Raspberry Pi doesn't include NEON.
I can't find any evidence of it but I wouldn't be surprised if it was out there. OpenMAX - which is an A/V API designed for mobile hardware like ARM CPUs that includes the JPEG encode/decode functions - is what is put forth for ARM-based products using NEON from what I read.
I didn't realize it, but Chromium (and Google Chrome) use libjpeg-turbo. All along, I was building Chromium with -Duse_system_libjpeg=1 and so it was just linking to my libjpeg 8a. So now I'm using 0 for that, and -Duse_libjpeg_turbo=1. (Those are defaults if neither of those defines are set,.according to common.gypi)
Might as well be using the optimized fork, because jpegs on the web are all mostly baseline anyway. That's probably one of the best uses of it, in a browser.
I don't think it's "drop in compatible" (don't want to recompile things linked against my system's libjpeg) but I'll consider it for next time for my system's jpeg library.
It's supposed to be drop-in compatible - everyone tells me that at any rate - but I have not dared tried to uninstall libjpeg simply because it's tied to many pieces of my distro and I don't have any spare machine to test removal of it plus any installation of any software that depends on libjpeg would simply re-install it as a dependency anyway.
Your article is misleading, because it implies that the changes between 1.3 beta and 1.3 final were the only changes relative to the 1.2 branch. In fact, numerous other more "exciting" changes were introduced in 1.3 beta, but it is our convention for the release announcement to describe only the changes since the last release (which in this case was 1.3 beta.) The changes introduced in 1.3 beta can be viewed here.