Xastir
Xastir copied to clipboard
Xastir
Remove old ImageMagick API breakage workarounds (was "Remove ImageMagick support, require GraphicsMagick instead")
Years ago, we floated the idea of dropping ImageMagick support in Xastir altogether, and just requiring GraphicsMagick. ImageMagick's API used to change very frequently out from under us, and as a result the code is peppered with ifdefs in order to test what version of ImageMagick is in use and to work around API instability. These are all referencing the MagickLibVersion preprocessor macro. Most reference versions prior to 0x0538-0x540. It is highly unlikely that anyone even has those old versions anymore, and it may be that one would have to dig up a landfill to find a system that still ran such a version. The current version I have installed (which is updated often) is 0x699. The last time anyone added a backwards-compatibility ifdef was in 2003.
When that idea was floated, it turned out that there were a couple of Linux distributions that could not allow you to have both ImageMagick and GraphicsMagick installed from a package management system at the same time, because they both installed files of the same name into the same place. I believe the last time we saw that was over 9 years ago.
Now, almost all distros and all OSen have sane packaging of these two products so they can coexist. It may make sense now to remove the support for the highly unstable ImageMagick and just say we require GraphicsMagick full stop end of story.
Marking this as "Call for discussion" to give folks time to weigh in on whether they can reliably build Xastir with GraphicsMagick on their system, without interfering with other packages that require ImageMagick. It may even be that nobody is using ImageMagick with Xastir anymore, because we've been telling folks not to for so long.
At the very least, even if we continue to support ImageMagick/GraphicsMagick interchangeability, it is very likely we can get rid of the 15-year-old ifdefs supporting versions prior to that date, simply for the sake of housekeeping.
I much prefer GraphicsMagick over ImageMagick for a variety of reasons. GM is a fork of IM, but is more stable.
That being said, I find myself sometimes installing a Linux that doesn't have GM so I pick IM instead, knowing that Xastir will work with either. As for me, I'm willing to take on the burden of installing from source for those cases where the Linux that doesn't have a GM package available. Most people would rather not install from sources though.
Will we be putting any burden on users if we force the use of GM and cut out IM support, for those that don't have GM as a standard package? That's about my only concern.
Tom says: "I'm OK with keeping ImageMagick support in the code, so long as we can pitch the 15-year-old ifdefed workarounds for old, busted API issues."
I say: +1 to that.
K. Looking over the history, we haven't jumped through ImageMagick API breakage firedrills in many years --- either they stabilized it and don't break us, or nobody uses it. So the heartache I remember about how unstable they were is a really old scar.
Since Xastir does apparently still work with ImageMagick and we're not expending energy chasing their changes, I'm changing this issue title and the focus --- rather than abandoning support for ImageMagick, let's just get rid of the ugly code that works around 15 year old API changes.
The FreeBSD port/package defaults to GraphicsMagick and has done so for quite. I have no issues with removing the old hacks and only supporting recent versions of contributing packages.
Debian downstream here - hi!. We have both imagemagick and graphicsmagick in the repos, so either way I can build and support if there's a change.
Outside of that, go ahead and clear out the old hacks - a leaner codebase is always nice.,
Honestly, with ImageMagick7 having so radically changed that we probably can't support it (most notably because HDRI is the default), it probably makes sense to reconsider dropping ImageMagick support from Xastir again. C.f. #148
Supporting HDRI would require a complete rewrite of our image access code, which currently assumes that images are represented by integer channels for each color. HDRI treats the image pixels as doubles instead. Completely incompatible with our approach.
HDRI is great for real high definition imagery. But the sort of mapping images we have traditionally targeted with our Magick support are not high dynamic range images and never will be --- HDRI is really intended for digital darkroom work, not map display.
So with the ImageMagick project really chasing after that use case, it is unlikely we'll ever really support ImageMagick 7. So how much energy do we want to spend maintaining ImageMagick 6 support?
Not that I've had any time even to address the "strip out ancient backward-compatiblity workarounds" part of this issue, either.