#47808: port:jpeg proposal to prepare for making port:libjpeg-turbo the default jpeg dependency --------------------------+-------------------------- Reporter: rjvbertin@… | Owner: ryandesign@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: jpeg | --------------------------+-------------------------- Comment (by rjvbertin@…): Replying to [comment:5 cal@…]:
But yet, it is much more complicated than our standard approach of 1. replace port, 2. fix dependencies, 3. revbump dependents. ... No, but it adds significant complexity that we should avoid, IMO. Just in the spirit of keeping things simple, where they don't need to be complex.
Much more, significant (to what level of confidence?) complexity? Now who's seeing problems where there really aren't? I've taken care that this change can be pushed without rebuilding a single port except for port:jpeg itself, which takes about 30s on my system (going on 4yo and with an HDD instead of an SSD). It also carries no inherent obligation at all to follow up on my suggestions on how to use it, and I'm not even thinking of obliging everyone to keep having the port installed. Plus I did all the work...
I believe that most of our users do not directly use libJPEG – essentially, most of them probably do not care which specific JPEG library is being used, as long as the end result (i.e. their use case of rendering or encoding JPEGs) continues to work. And, if due to a change we make, this use case becomes faster, that's probably even a welcome side-effect.
I'm not saying I care what libjpeg version is being used most of the time, except when dealing with photos when I want to be sure to get the correct/best rendering. That, and the fact that libjpeg-turbo v8 is a 2-releases wide emulation layer on top of something that was ABI compatible with libjpeg v6 (and even that version wasn't guaranteed to yield identical results) are reason enough for me to want to maintain the port. ---- ''For the most part'', libjpeg-turbo ''should'' produce identical output to libjpeg ''v6b''. The one exception to this is when using the floating point DCT/IDCT, in which case the outputs of libjpeg v6b and libjpeg-turbo can differ for the following reasons: <snip> While libjpeg-turbo does emulate the libjpeg v8 API/ABI, under the hood, it is still using the same algorithms as libjpeg v6b, ''so there are several specific cases in which libjpeg-turbo '''cannot be expected''' to produce the same output as libjpeg v8'': -- When decompressing using scaling factors of 1/2 and 1/4, because libjpeg v8 implements those scaling algorithms differently than libjpeg v6b does, and libjpeg-turbo's SIMD extensions are based on the libjpeg v6b behavior. -- When using chrominance subsampling, because libjpeg v8 implements this with its DCT/IDCT scaling algorithms rather than with a separate downsampling/upsampling algorithm. In our testing, the subsampled/upsampled output of libjpeg v8 is less accurate than that of libjpeg v6b for this reason. -- When decompressing using a scaling factor > 1 and merged (AKA "non- fancy" or "non-smooth") chrominance upsampling, because libjpeg v8 does not support merged upsampling with scaling factors > 1. ---- Not so long ago when I was still in vision research this could have been a much bigger deal for me, now I don't even know for sure anymore how many of my former colleagues are still using OS X (and MacPorts as a resource). Re: Performance: it was a comment in LibVNCServer's output that got me interested in libjpeg-turbo. This seemed the kind of application where a 2-4x decoding speed-up would be noticeable, but in the end I can't say I noticed anything. Other comparisons I ran on even the largest jpeg images I have around showed similar results: I suppose the decoding speed gain was insignificant compared to other bottlenecks, i.e. the overal process not decoding-constrained. So I'm tempted to think that you're preparing a change with a huge overhead for nothing much if a (mostly theoretical) performance gain is the sole reason. What I do care about has been rehashed a couple of times already apparently without leaving much impression. I'm using a number of ports (including KDE and GTk-based apps) as alternatives for "native" applications, and not just from time to time, and without a backup OS X machine. I'm using "devel" versions of Qt4, Qt5 and kdelibs4, and there's just no way I'm going to get myself in a situation where I have to rebuild all of those plus the GTk ports at the same time because a basic library has been downgraded (which in turn was necessary because it was updated for updating's sake) without keeping the newer version around at least during a grace period.
I would even argue that MacPorts should not be a show-case of what FOSS can be installed through it, and for that reason '''not''' keep the jpeg port around. We should just make a sane choice for most of our users that really don't care which JPEG library gets used, just as the big Linux distros have done by replacing jpeg with libjpeg-turbo.
The situation is different with the big Linux distros and their users. Their packaging/distribution systems are usually much more powerful than MacPorts', and there are no such things as "variants" which oblige users to build from source instead of using the provided binary packages. But most of all, they've never been in the situation where they had to downgrade. I have a hunch that more than 1 distribution would have decided to roll their own v9 emulation for libjpeg-turbo because apparently that `can be done easily enough`. Linux distributions also don't have activation/deactivation of older and/or alternative port versions. You did realise I hope that by doing an all-out replacement of port:jpeg by port:libjpeg-turbo, it becomes impossible to re-activate an older version of a port that was built before the change (and probably cannot be rebuilt anymore) without re- or de- activating *all* other ports depending on the jpeg replacement? The simple fact of providing libjpeg.9.dylib (which doesn't bite anything or anyone) makes that issue go away. -- Ticket URL: <https://trac.macports.org/ticket/47808#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X