An example of the bug is present in this screen capture:  https://i.imgur.com/h2SmH28.mp4

Hello,

Looking at the screencast, it looks like the problem is the export time, i.e. the time of the export dialog to **disappear**, not the time to appear, which is contradictory to your description.

So which is it exactly? The time for the dialog to appear, or the time to export (hence dialog disappearance after hitting "Export")?

Oh ok thanks to someone on IRC, I just understood. This is about the time the second dialog (file-format specific one) appears. I missed this.

This same person on IRC also says one experiences 3-5 seconds of lag under Windows for the 2.9.6 build but not as much as you get.
Anyway I guess we'd need to have a MacOS developer to see if one can reproduce this issue.

Yes, that is the issue I'm having.  The file-format options dialog itself takes several seconds to appear. In addition to this, the dialog itself does not accept input from the mouse, but that's an entirely different bug altogether.

I also get the bug with other dialogs on occasion, such as the Open As Layer dialog, but the issue with the Export As dialog is a persistent and consistent error that I experience every time I use GIMP.

So, after a few months of not finding a solution, I decided to see if the issue could be replicated on a new user in macOS and it seems as though it cannot.  I have also recently discovered that the issue does not appear on my MacBook Pro, which I use rarely enough that I haven't made any significant changes to it.

It appears that something in my primary user profile is causing a conflict with GIMP and is causing the export windows to appear slowly.  However, I do not know how to test to see what could be causing the conflict.

Creating and examining diffs of the GIMP profile directories of the different users would be an approach, done on both the folder and file content level.

Okay, so I went through several different steps to troubleshoot the problem and I'm pretty much convinced it has nothing to do with the profile and probably not even GIMP itself.    

1. I compared the contents of the original profile with a brand new profile generated on a new user account.  The only differences were the user-generated files such as palettes, tool options, and gradients.    

2. I compared the read/write permissions of both profiles (both the folders themselves and all enclosed files) and did not see any differences.    

3. I backed up the original profile and replaced it with the new profile. The problem persisted.    

4. I backed up the original profile and deleted it, forcing GIMP to re-generated a profile upon the next start up. The problem persisted.    

5. I completely removed GIMP and all GIMP-associated files and attempted to reinstall the latest version (2.8.22). The problem persisted.    

6. I completely removed GIMP and all GIMP-associated files and attempted to install an earlier version (2.8.18). The problem persisted.

7. I deleted the new profile on the new user account and replaced it with the backed up original profile from the main user account and did not experience the problem.  I tried this with my MacBook Pro, as well, and again did not encounter the problem.    

So, I think I can reasonably conclude that the issue isn't with the GIMP profile and would be willing to hypothesize that the issue isn't even with GIMP itself.

Thanks for the detailed tests!

Still, even though GIMP is not likely the direct culprit, I assume there is something we can do better (there always is!), whether in GIMP code or by patching upstream one of our dependencies.
If we could know what "hangs" the dialogs, maybe we could bypass the issue.

So if you could ever find the different between the 2 user profiles (I don't mean the GIMP configuration files now, but really everything else which makes that it works fine by creating a new user on the same OS) and especially if you discover what makes GIMP go slow, that would help us to diagnose the issue and try to have it bypassed and never happen again.

Also this issue reminds me of bug 767521 (which happens on Windows though) where some people have non-existent floppy drives configured and that makes open/save/export dialogs slow to open as well.

It is a different OS here, but could it be something similar?
Would your main user have some non-existing device configured? Or maybe some remote device on the network permanently configured?

I'm not sure how that would hold GIMP, I myself have network devices which sometimes are even unreachable, but I don't think that ever made the export dialog slow to open (yet I use another OS, Linux, and maybe that sort of things are handled differently there)

I combed through System Report and Disk Utility to see if I could find any external or remote network devices that weren't accounted for and I could not find any.  That includes floppy disks; however, the iMac has not had a floppy drive since its introduction in 1998 and I'm not even sure macOS still has built-in floppy disk drivers.    

I disconnected the "readyshare" utility that my NETGEAR router installed when I set it up and that didn't resolve the issue.   

One of the things I know that is different between this primary account and both the secondary account on the iMac and the account on the MacBook is that my primary account automatically backs up files to an external hard drive using Time Machine, whereas Time Machine is not yet configured on the other two accounts. So, first, I disabled automatic backups; that did not resolve the issue.  Next, I disconnected the drive altogether; that also did not resolve the issue.  



I think I'm going to slowly migrate all of my files and applications over to the new user account.  Before I do that, I'm going to make a log of all the applications I typically have running at the same time (both foreground and background processes) and then test them one by one in the new user account until I find anything that conflicts with GIMP.

Thanks for testing so thoroughly.

We'll leave open the report. If you ever find the culprit which makes GIMP go slow, we should have something to start investigating! :-)

I managed to isolate the probable cause of the issue: fonts.  I have approximately 1.53 gigabytes of fonts installed to /Users/jesse/Library/Fonts on my primary account.

When I migrated the fonts over to my new account, I was able to immediately reproduce the issue with the file export options dialog. The dialog took approximately as long to appear (seven seconds or so) that it does on my primary account.  When I remove the fonts from the folder, the issue cannot be reproduced.


With some further investigating, I found that the issue can be reproduced if the fonts are installed to /Library/Fonts and /Users/jesse/Library/Fonts.

However, if the fonts are installed to the GIMP Profile itself (/Users/jesse/Library/Application Support/GIMP/2.8/fonts) instead of either of the previously mentioned folders, the issue cannot be reproduced.

Does OSX have a utility which can monitor file accesses per process (which files are accessed, what is done to them - open, read, write, close, ... - and how long this takes)? If yes, then it might be useful to run it on the GIMP process to see if that time is spent on any font-file related actions.

Also, check if your fontconfig font cache is ok. If it isn't, then fontconfig tries to rebuilt it at some points, for example when starting and ending GIMP. If these take longer than you expect them to, then this might indicate a corrupted cache.

Okay, just to be clear here, we're venturing into unfamiliar territory for me, as I am not a developer.  That said, I'm going to try to provide what I think is relevant information as best as I can.  

In Xcode 9.2, there's an application called Instruments.  This application analyzes and visualizes application performance as a timeline detailing any event that occurs while a selected application is running.  For this test, I ensured that the fonts were stored in the folder which was causing the issue to occur and I started both Instruments and GIMP and started recording.  I ran through the process of opening a recent image and attempting to export it as a PNG.   

I'm attaching the data from the moment I clicked the "Export" button to the moment I cancelled the export.  The table also includes some annotations I added, like the number of seconds it took for the action to complete and the actions I performed myself.

Created attachment 366102 [details]
File Activity - GIMP

A table showing the file activity from the moment I clicked "Export" to the moment I clicked "Cancel".

Thanks this is very interesting.
The column "Seconds after app start" indicates when the associated function started or ended? Wasn't there data about how long each function lasts (from function start to function end)? This would be the most interesting data IMO.

Also I see that km_scan_missing() lines are all red. Was it set in red by Instruments application or are you the one who did because you think that's the problem? Knowing the duration inside these functions would be very useful to confirm this.

In any case, km_scan_missing() is a function in GIO and the description says:

>  * Traverses through a list of missing files, tries to start watching each with
>  * kqueue, removes the appropriate entry and invokes a user callback if the file
>  * has appeared.

Well, "traverses a list of files" makes it indeed a possible culprit for a slowness which seems to appear when you have a lot of fonts. It would be worth investigating.
If you can have more data and in particular the duration inside each call, this would be extremely useful!

Hmmm… also I see this glib code uses locks and it seems like it was run several times. So it is highly possible that threads may be blocking the GUI if one of the call is inside the GUI thread.

Seeing that it uses /etc/fstab which lists disks or partitions (if it is anything like in Linux), I guess whatever it watches is storage-device-related. Not sure yet how it is related to fonts yet, but maybe we will soon. :-)

Okay, so the Instruments application records timestamps (in seconds), but for some reason, it does not display that information in the details table.  You have to click on each individual line to see that information.   

I'm going to have to find a different application to do this with, because honestly, I don't want to sit here and hand-jam 16,800+ timestamps into an Excel document.   

That said, the following is a list of timestamps between lines 16,827 and 16,836 (between the first instance of km_scan_missing and when the Export Options dialog was cancelled):  

16,827: 275.380461 seconds (km_scan_missing)
16,828: 275.631638 seconds
16,829: 275.631672 seconds
16,830: 275.631716 seconds
16,831: 279.380690 seconds (km_scan_missing)
16,832: 283.380582 seconds (km_scan_missing)
16,833: 287.380733 seconds (km_scan_missing)
16,834: 291.381020 seconds (km_scan_missing)
16,835: 295.379704 seconds (km_scan_missing)
16,836: 299.379719 seconds (km_scan_missing)

Created attachment 366106 [details]
File Activity - GIMP - Test 1

A full list of the file activity from start-up to close.

I've attached an Excel document which shows the file activity from startup of GIMP through opening and exporting an image and closing the application. I manually entered all of the timestamp information to include a calculation of the duration for each action.   

The file export process begins at approximately step 835.

Hey Kris!

Adding you in Cc to this bug report, hope you don't mind!
The reporter has reproduction steps and statistics on function performance which seems like it should be not too hard to reproduce and fix (hopefully).

If you have some time for GIMP some day, I guess this could be a good macOS bug to look into. ;-)
Not today of course, since I expect you'll spend the day with your family!
Happy new year!

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1196.