I hadn’t touched Gimp in five years or more but last month I had to slice up some large images for easier printing and Gimp rescued the project. I found it easy to use, mostly intuitive, the install was easy, the UI was snappy, and all of the features I needed were available. I have to give a big thanks to their dev team for providing this software and saving me from the Adobe nightmare.
Totally agreed. Specifically, I can never get the “ants” that should show up when you select something. It’s an ongoing bug that was just never fixed. So I just have to remember that a thing is selected. Quite irritating.
The "ants" got fixed sometime in the past few months, I believe, and thank goodness: it really did make GIMP almost impossible to use for anything complicated enough to need GIMP. (But they've been working on my M1 Mac for a while now.)
I'm still waiting for GIMP 3. At this rate I'm not convinced it'll ever come out. GIMP kinda looks like a discontinued project these days.
FWIW, the Intel version has always worked okay (well, as okay as GIMP can feel) on Apple Silicon. It's blurry and low res and old-feeling, but compiling for ARM can't fix that.
In 2016, I identified and wrote about the lack of retina support for Gimp here https://artplusmarketing.com/gimp-and-inkscape-on-retina-mac... . I know Inkscape got retina support since then, but as I understood it, Gimp was waiting for better Mac GTK support or something. Does anyone know if Gimp has fixed the retina issues I wrote about years ago yet?
I wonder why Gimp doesn't get more backing like Blender to increase the pace of development. Not enough interest from big backers? Surely many would benefit from dumping Adobe if alternatives could be on par.
Its internal dev-people world is different and doesn't take direct critique as opportunity (or compliment e.g. I want to contribute with my better-outcome-vision) in the same way some other projects do.
Not good or bad (unless you love one way more), more like comparatively differing in that way
Just comparing to how fast some projects like OBS evolve for example both in features and ease of use, Gimp feels very slow and unfortunately not focused on usability.
Krita kind of leads the pack in the "FOSS image editing development fund" category with 17k/month. It's not the same primary use case but there is enough overlap in what it can do that I'd say GIMP is neither in the lead enough or differentiated enough to garner significant support easily.
Krita is indeed pretty popular for artists at least and yeah, there is an overlap. But still, Blender seems to have way more massive backing in general.
I think the difference is the amount of competition. Blender's alternative is Autodesk. Meanwhile there are plenty of alternatives to Gimp as seen in these comments.
Why is the Gimp website so useless. I wanted to see if they still have the strange UI with floating windows but couldn't find a screenshot of the actual software on the site.
You can run GIMP in either single window or multiple windows mode, there is a setting in the "Windows" menu that switched between the two. The multiple windows mode is the default and IMO works better if you are using a window maanager with a virtual desktop dedicated to it (or graphics apps in general). In my Window Maker-based setup i have a virtual desktop for graphics apps and i have it configured to always place GIMP windows in that virtual desktop. The main thing i'd like is being able to preserve the tear-off menus across launches (GIMP remembers the various window locations but always closes any persistent menu windows).
If the GIMP team's experience is anything like ours (Wireshark), it's because a significant percentage of your dependencies are pathologically blind to the concept of fat binaries, so you'd end up having to do the grunt work of supporting fat binaries in both your application and your dependencies. It's a lot easier to just add a CI builder for each architecture and ship separate packages.
GIMP is already a pretty big download (~240MB), so saving users another significant fraction of that is nice. Also helps keep their mirrors' costs down.
I actually appreciate not having universal binaries. I almost always prefer to have a smaller footprint and the current app for arm64 is 874.4 MB according to Finder.
I'm not affiliated with Gimp and don't know why they didn't support fat binaries in the end; but I did look into compiling Gimp as a Universal Binary on my own at one point. My experience matches those of another comment, which is that not all dependencies supported compiling to fat binaries (i.e. you couldn't just add a bunch of flags and get a fat binary at the end). The only solution I thought of was to compile for both platforms and then lipo all the built files. The main problem is I couldn't figure out a strategy to do this without making the build scripts into a gigantic mess.
I know a lot of people like to bash on the Gimp and complain about features it's been missing for years (I might have even done some of the complaining myself!) but I really appreciate the work they're putting into it. This kind of low-level work with an ancient codebase can be pretty nontrivial and thankless work. Thanks, Gimp team!
What's so hard about porting to a new hardware arch? Why would building for ARM Macs be any different than x86? Unless you have assembly code it's just a matter of changing a compiler flag, isn't it?
A couple of issues that came up for me when porting from x86 to ARM recently:
1. The x86 architecture gives programmers a lot of memory ordering guarantees, so that communication of values between threads does not usually need memory fences. ARM64 does not give so many guarantees, meaning that multi-threaded code may need additional memory fences to avoid data races. But data races due to out-of-order memory updates are hard to diagnose.
2. Page size in macOS is 4 kB on x86, but 16 kB on ARM, so if someone has hard-coded the page size rather than calling sysconf(_SC_PAGESIZE) this may need to be discovered and fixed.
Aside from the points in the other comment, it takes time to change the build/test/release process for a new architecture. In some codebases it's a matter of adding a line to a Makefile, in others it's writing hundreds of lines of Bazel and a new CI pipeline.
Getting a Silicon build of Gimp wasn't actually that difficult. I know at least one other person besides myself that had gotten a build working from source and published how to do it in some form. The problem is that the CI system Gimp used for the Mac build did not have ARM runners, yet. This meant that to produce the production build required cross-compiling from an Intel Mac. While I'm sure it's possible to accomplish this, it was quite tedious and I gave up. As an example, one problem was that the Gimp build process builds tools that need to be run on the system doing the build and just splitting out those parts from the parts that need to be compiled for the target system was tedious.
A recent change in Ardour that used int128_t did not break on ARM nor did it break on unoptimized x86_64 builds, but did break on optimized x86_64 builds. That's just one example of the sort of platform-specific madness that may need to be faced and chased down.
Just providing a link to stackoverflow discussion that seems to relate to this, as I was curious about the details. Looks like it was undefined behavior relating to casting pointers.
What is true is that if you want users to be able to just download and run (rather than download, run an obscure command, and then run your software), you have to pay Apple to notarize your builds.
> rather than download, run an obscure command, and then run your software
This also isn't true.
On a Mac (or on Windows) software that has not been digitally signed will show a scary dialog box telling you that software you download off the internet might be malicious.
On the Mac, to bypass this, you just right click the software and pick "Open".
Porting complex applications (especially those written in C) from x86 to ARM can be pretty non-trivial.
I can't speak to the GIMP code in particular, but I've done several x86->ARM source ports of other complex software, and each time there are things which work on x86 and don't work on ARM, resulting in nasty crashes, or worse.
GIMP already supported ARM though, this is about "Apple Silicon". Since the post itself doesn't mention specific challenges, I guess it serves more to inform macOS users of the availability than foster discussion or provide any insight.
