Gimp 2.10.32 on Apple Silicon (2022) (opens in new tab)

I just use photopea in the browser these days. It's pretty much exactly Photoshop, at least for my non-advanced purposes.

Affinity tools are great.

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.

This is my experience entirely.

I've been using GIMP for most of my life, but a lot of little things are off on Macs. My GIMP experience translates nicely to Pixelmator

You'll want GIMP 3.0 which updates the app to GTK 3. 2.10 still uses GTK 2.

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

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.

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.

There are lots and lots of alternatives, and gimp is worse than every single one of those.

agreed. it downloaded faster than it took to 'install' the full version to 'applications' folder. leaving a seed running for a while to help out...

The strange UI is GTK and it hasn't been floating windows but instead a MDI (single window for controls and images in tabs) for over a decade.

You can find screenshots on the tutorial pages: https://www.gimp.org/tutorials/

Hasn’t used floating windows by default for like 15 years.

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.

Along with the other answers here, using a newer Xcode and macOS SDK in order to build for M1 can limit compatibility with old macOS (OS X) versions.

hmm as a user I really don't like downloading binaries that are almost twice the size needed and of which I won't use half of

Mac users are well adjusted to having to pick the correct binary by now and the consequences of getting it wrong are fairly minor.

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 wouldn't be surprised to find they're using a build tool chain that can't produce a universal build ... I've run into that before ...

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.

Probably comes down to either inline assembly or dependencies, or both.

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.

Building open source software packages for apple is difficult because you need to pay for apple computers to run the build software.