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.

I have been a loyal Gimp user since early days. I never found the MacOS experience to match that of the Linux or Windows environments.

Pixelmator has been a suitable and far superior replacement. It might not be Photoshop level capabilities but it more than covers my requirements.

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?

Meanwhile GIMP 3 is progressing[1] slowly but steadily.

[1] https://gitlab.gnome.org/GNOME/gimp/-/milestones/3#tab-issue...

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.

I love that this project provides a torrent download. Nice and fast for me and I feel like I'm less of a burden on their mirrors.

It also runs on VisionFive 2 (RISC-V proper), for what it's worth.

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.

Why not offer this as a universal binary? Seems like a bunch of extra work to generate two separate DMGs and try to point users to the right one...

Regardless, congrats to the team! Though, I'll note this blog post is from almost 6 weeks ago now.

Recent and related:

GIMP Turns 27 - https://news.ycombinator.com/item?id=33808435 - Nov 2022 (291 comments)

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?

There days for minor adjustments I just use PhotoPea (the online photo editor). If I need more than that I use Affinity Photo or Photoshop.

The software that I would love to see running well on macOS (Intel or ARM) is Inkscape.

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.