[MacPorts] #47808: port:jpeg proposal to prepare for making port:libjpeg-turbo the default jpeg dependency

[MacPorts]

#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