Subsequently to updating to mac os Big Sur, I opened Gimp and noticed straight away that all the drawing tools were jerking around. You could move the mouse to a spot and it would take about a second for the tool to jump to it. While this in and of itself renders the program unusable, I still tried messing around with color grading some photos and noticed that basically the entire program is running slower as a result of the update.
Unfortunately we have no contributors on this OS lately (and for the last few months!). Your best luck is to spread the information that GIMP is looking for macOS developers (GIMP is fully community-developed).
In the mean time, please record a performance log demonstrating the issue, and attach it to the report:
I got irritated with the performance drop, so I've had a play around.
Alex (current OSX build maintainer?) commented on this about an earlier issue and one of the workarounds mentioned - switching my iMac display to sRGB - does get me back some of the lost performance on Big Sur, but not all - some mouse-drag-ops still seem sluggish.
A quick inspection of a GIMP profiling file only showed me CPU load (25% - i.e. a loaded core) /etc at sampling times, so nothing useful there (maybe I'm doing it wrong?).
But I did grab a profile using the Xcode Instruments tool, and this does seem to indicate that a lot of the time if going into colourspace conversion
I've seen another graphics-heavy app suffer in CGContextDrawImage (and convert_icc) before, so I wouldn't be surprised if this was one of the bottlenecks involved.
I've also managed to get some approximation of a GIMP 2.10.20 build on my iMac, starting from Alex's published build with some random hackery to get past the breaks. I'm up to the "Importing signing certificates" step, blocking on "
osx_crt" and "
osx_crt_pw". I'm not sure who else has tried, and how far they've got with this, but it'd be nice to know if anyone else is looking?
@DesMcGuinness As far as we know, you are the one who went the furthest ever since @samm-git (indeed the macOS maintainer these last few years) didn't get much in touch.
If you are interested, I can make you a test branch on the gimp-macos-build repository, and if you make any merge request against this branch, I will just merge it. The big advantage of this is that it will generate automatic builds on the CircleCI instance, so that you can test on the CI environment, get familiarized and possibly fix the build. If at some point, you think to be getting somewhere, we can start merging your changes to the actual master branch and possibly you could become a new maintainer for the macOS build (hopefully @samm-git will be back some day and then we'd have 2 maintainers, which will make some redundancy! Finally!).
Are you interested? Just tell me and I'll set things up.
I'm pretty sure that OpenTTD (https://github.com/OpenTTD/OpenTTD) also had problems with slowness related to conversion of color profiles though this was already before Big Sur.
I don't know if @samm-git used his own credentials to sign or if they were supplied by the GIMP team. If the last case is true there probably could be a discussion about supplying the credentials to another "trusted" person.
It might be a good idea to join our IRC channel irc.gimp.org/#gimp if you are interested in helping maintain our MAC builds to discuss this.
I don't know if @samm-git used his own credentials to sign or if they were supplied by the GIMP team. If the last case is true there probably could be a discussion about supplying the credentials to another "trusted" person.
For the main repository, I am also maintainer on it (only by name, exactly for cases like this) so I can give access. For the Circle-CI part, Alex did the main stuff and I have some access though I have no idea how it actually works (I never spent more than 10 mins there). Though it doesn't matter much because any commit on the main repo will still trigger builds.
And if really we need some further admin access which we might not have, we can contact the company behind this service directly (they provide us the service for free in the name of GIMP, not Alex personally). Anyway we can make things work.
It might be a good idea to join our IRC channel irc.gimp.org/#gimp if you are interested in helping maintain our MAC builds to discuss this.
Indeed this is the best advice. We can really collaborate best with people through IRC.
I'm experiencing the same lag on MacOS Big Sur. Gimp ran very well on MacOS Catalina.
I have some previous experience with GTK programming but not with the Gimp codebase. If someone could point me on where to start looking, I'm interested in helping to solve the issue.
After some initial investigation into this, I've spent some time trying to get GIMP building for MacOSX again. That's been my focus, so that we have a buildable base from where we can investigate.
Let me summarise what I was looking at:
Initial investigations showed a lot of time was being spent in colorspace conversion (my screenshot from Instruments, above)
I manually ran through the items in the CI script for the gimp-macos-build project (see .circleci/config.yml), hacking/fixing until I could proceed
the current version of this script is successfully building on our CI server, so you should be able to re-create locally by running the steps in turn.
so, if you want to try, I'd start from here
Once I had gotten as far as building gimp from source, locally, I could start instrumenting it
it appears that GdkQuartzView.drawRect() in {src}/gtk+-2.24.32/gdk/quartz/GdkQuartzView.c is being invoked at a rate which is consuming a whole CPU, and is being asked to redraw the entire underlying image surface on each event-notification
the frequency of mouse-move events means there are lots of events to process
the API meant to determine the bounding rect(s) of the region requiring change (NSView.getRectsBeingDrawn:count:) only appears to return a single, whole-surface rect, regardless of the event.
e.g. even a mouse-move when the caret is not over a GIMP window is requesting a full-redraw.
But I only have Big Sur machines here, so I can't tell if this behaviour is actually different from Catalina.
However, with colourspace conversion between aRGB (8-bit, GIMP internal) and iMac (10-bit), I believe this is a major contributing factor in the slow/laggy performance - basically, GIMP is swamping a CPU.
To reduce the load, switching my screen from iMac to sRGB returns some of the lost performance.
but there are other factors, including that GIMP (2.10.22 is my working version at present) is using GTK2, and is far behind current master/head GIMP, including an entirely new MacOS backend to replace the quartz code.
Help this helps as a starting point, because the more the merrier and someone with experience in GTK (and the event loop in particular) may spot something I'm not seeing due to lack of familiarity.