More specifically my 'about' dialog shows GIMP 2.8.16

Is it only the Open dialog? No problem on the save, export, or any other dialogs?

Just tested to see... yea save and export are also both equally slow.

Could be this: 
https://superuser.com/questions/979504/load-dialog-disk-access-slowdown-on-windows-10/

James Ford > could you try to disable your floppy drivers (which you probably don't have, do you? :P) in your BIOS, same as the users in the link that Michael is pointing to? Then tell us if this fixes your problem.

I'm not really willing to go through that massive wall of text, nor to fiddle in my bios settings, for the purpose of shaving of 10 seconds on save dialogs when i use gimp. I'll just use paint.

That said, for purposes of diagnosing this report, i am running windows 10 and if i had to guess id say its the same issue reported there.

As you wish. Yet if this is indeed the same issue, this is a Windows bug (not GIMP's), thus you may encounter the problem with other software, as did the user with Chrome and other software. Even without using GIMP, fixing this would be in your best interest.

Also if you don't have any floppy drives (I don't think I saw any computer with floppy for many many years), I don't think this is too much fiddling to just disable whatever support for this there may be in your BIOS.

For sake of completeness though, the link said that Chrome managed to bypass the issue at some point. It could be interesting if we could figure out how they did it.

My file dialog in Visual Studio 12 (WPF) is fine. 
My file dialog in the MonoGame Pipeline Toool (winforms) is fine.

These are the same versions of the software I was running before on windows 8, and now they are running on windows 10 and seem unaffected.

Seems like it would be pretty straightforward to run a profile during a File > Open, and that would tell you what exactly its hanging unusually long on. Well, if there is a gimp developer running windows 10 anyway.

> Well, if there is a gimp developer running windows 10 anyway.

That's one problem. We have no developers running Windows at all as usual usage. Since you seem to be a developer as well, you are therefore very welcome! :-)
We would be happy to get a patch about this problem.

> Seems like it would be pretty straightforward to run a profile during a File > Open

The second problem is that this bug is pretty rare. Most users don't have this issue. So yes it would be no problem to dig up the source of the bug if we could reproduce it, but we can't.

Personally my only access to Windows is through a VM and I don't think I can reproduce the issue of an absent floppy in Virtualbox (or if it is possible, I welcome the configuration steps).

So i just went into my control panel and noticed there were in fact 2 floppy drives shown in there, with drivers installed. Note that I have no actual floppy drive nor have I ever. 

I disabled both of those drivers right there in the control panel, didn't even restart. Launched gimp, and behold the open dialog appears like instantaneously.

Do you have any GTK+3 application with file open/save dialog to check if the problem occurs there?

If the issue does not happen with GTK+3, I think we could just tell people to do this until we port GIMP (not ideal, but lack of Windows developers and rarity of the issue makes this less prioritary). On the other hand, if that still happens there, we should probably try and discover how other programs dealt with this issue.

So can we close this as NOTGNOME now if it's indeed a bug in Windows 10?

There is still the fact that apparently other software used to have this problem and were able to bypass it. Even though the core issue is obviously a Windows 10 bug, it seems to be a fairly common one and a quite bad user experience. If there is a way for us to bypass the issue as others did, it would be worth looking into it. This would be the idea resolution.

Now there is also the problem that we still have no Windows developers…

I also have this problem (2.8.16). I have done some compiling of Gimp for Windows before but I'm not familiar with the code base. However I might try rooting around to find the issue if I have time.

I've never seen any evidence for this floppy drive thing. It sounds like some kind of myth. The only time I've had something similar (which is where the floppy drive thing might come from) is having certain network drives linked to drive letters which I know can hang windows while it waits for a connection. However I have deleted all my network drives.

So what library does Gimp use to open file in Windows ?

(In reply to Michael Z Freeman from comment #15)
> I also have this problem (2.8.16). I have done some compiling of Gimp for
> Windows before but I'm not familiar with the code base. However I might try
> rooting around to find the issue if I have time.
> 
> I've never seen any evidence for this floppy drive thing. It sounds like
> some kind of myth. The only time I've had something similar (which is where
> the floppy drive thing might come from) is having certain network drives
> linked to drive letters which I know can hang windows while it waits for a
> connection. However I have deleted all my network drives.
> 
> So what library does Gimp use to open file in Windows ?

BTW I have no floppy drives in bios or system devices.

> I also have this problem (2.8.16). I have done some compiling of Gimp for Windows before but I'm not familiar with the code base. However I might try rooting around to find the issue if I have time.

This would be cool. You can also hang around on IRC (#gimp channel on irc.gimp.org) if you want to discuss with us and when you have questions: http://www.gimp.org/irc.html

> So what library does Gimp use to open file in Windows ?

Note that we advise to work on the master tree directly. A lot have changed since 2.8.x and working on 2.8 code may be a waste of your time. Of course, that's still good if you can have a bugfix for 2.8, but if the bug was to come back when we release 2.10, then this would not end up being a real long term resolution. Better to first fix master, and try to backport the patch later if possible.

Actually the first step could be to simply build master, run it and check if the problem still exists there on a Windows machine which experiences this issue. You may even just try to run the nightly build of GIMP (take the "Development series (2.9)"): http://nightly.darkrefraction.com/gimp/

If the problem still exists on the development version:
I don't know exactly how files are actually opened under Windows since we wrap all our I/O calls through a common library for all platform, which is GIO (in master especially). Unless we missed some parts when we ported. Not sure if GIO is the problem here.

Anyway if you have any issue, do not hesitate to ask (here or IRC), but bear in mind that anything Windows-related, you may be the expert rather than us. We really need a Windows developer!

(In reply to Michael Z Freeman from comment #15)

> I've never seen any evidence for this floppy drive thing.

What about the linked superuser.com article? It's actually an exceptional display of researching an issue on the Windows platforms - where most people there can't or don't go beyond a "it doesn't work".

First off, an obvious work around for people who don't usually open files this way: use the system or other file manager to drag files to Gimp to open them. I think the drop location is around the foreground/background colours swatch.

(In reply to Jehan from comment #17)
> > I also have this problem (2.8.16). I have done some compiling of Gimp for Windows before but I'm not familiar with the code base. However I might try rooting around to find the issue if I have time.
> 
> This would be cool. You can also hang around on IRC (#gimp channel on
> irc.gimp.org) if you want to discuss with us and when you have questions:
> http://www.gimp.org/irc.html
> 
> > So what library does Gimp use to open file in Windows ?
> 
> Note that we advise to work on the master tree directly. A lot have changed
> since 2.8.x and working on 2.8 code may be a waste of your time. Of course,
> that's still good if you can have a bugfix for 2.8, but if the bug was to
> come back when we release 2.10, then this would not end up being a real long
> term resolution. Better to first fix master, and try to backport the patch
> later if possible.
> 
> Actually the first step could be to simply build master, run it and check if
> the problem still exists there on a Windows machine which experiences this
> issue. You may even just try to run the nightly build of GIMP (take the
> "Development series (2.9)"): http://nightly.darkrefraction.com/gimp/
> 
> If the problem still exists on the development version:
> I don't know exactly how files are actually opened under Windows since we
> wrap all our I/O calls through a common library for all platform, which is
> GIO (in master especially). Unless we missed some parts when we ported. Not
> sure if GIO is the problem here.
> 
> Anyway if you have any issue, do not hesitate to ask (here or IRC), but bear
> in mind that anything Windows-related, you may be the expert rather than us.
> We really need a Windows developer!

Thanks ! It does still exist on the dev version. I'll try to get back to this. Maybe see you in IRC.

(In reply to Michael Schumacher from comment #18)
> (In reply to Michael Z Freeman from comment #15)
> 
> > I've never seen any evidence for this floppy drive thing.
> 
> What about the linked superuser.com article? It's actually an exceptional
> display of researching an issue on the Windows platforms - where most people
> there can't or don't go beyond a "it doesn't work".

OK, thanks. I'll take a look at that.

Hi,

> Thanks ! It does still exist on the dev version. I'll try to get back to this. Maybe see you in IRC.

Any chance you had a look at the problem and have a patch in progress? :-)

I am not always on IRC myself (but most other devs hang around there all the time). Did you pass?

Anyway keep us updated, we'd welcome patches on this topic (and any other Windows-related topic) and new developers happily! :-)

This may no longer be relevant to the current discussion, but I just wanted to mention... disabling the floppy drive in control panel wasn't a long term solution because it would reappear every time I rebooted, and I ultimately did check my bios and lo-and-behold there was a setting for "fake floppy a:".

Apparently this is a sortof legacy-software bios feature because it is (or was?) common for software to make the assumption that there was a floppy drive /else explode.

Anyway. If there is a workaround you guys are going to work into gimp such that future people don't end up needing to discover this bios setting they weren't aware off that's still worth doing imo. Just wanted to give a status update as the original poster.

So it was the issue I mentioned in comment 4.

For any future Windows developer willing to work on this, I have maybe a few hints. Try to build Chromium and check the problem doesn't exist there. Then checkout an older Chromium which has the same problem as GIMP, and confirm it. Then try to bisect (if Chromium uses git too, look for the command `git bisect`) to see in which commit this has been fixed or worked around and see if this same fix could be applied to GTK+.

This being said, I wonder if that has really been fixed in Chrome, because I found this bug report which looks very similar to what we have and is still opened:
https://bugs.chromium.org/p/chromium/issues/detail?id=103737
They don't mention floppy device, but more generically unavailable device could cause the issue there:

> - Having mounted network devices that are slow or disconnected.

Apparently there are other possible cases. Some say that opening the file dialog in a folder with too many files or folders could cause the application to hang as well (so some people propose to clean the Download/ folder empty, since that's the one opened by the browser; in GIMP, obviously, that would be other folders).

Comment 178 on their bug report looks like an important piece of information as well (though it is about closing tabs but maybe on Chrome that's related issues,  or just another similar issue, I don't know). I'll copy it here:

> For all the Windows users, if you also experience long waiting time (i.e., chrome is not responding) when you close tabs, then you are very likely having issues with JumpListIcons folder and/or JumpListIconsOld folder.
> 
> They are under C:\Users\<USER>\AppData\Local\Google\Chrome\User Data\Default\
> 
> You can navigate to these two folders and see if they are accessible and how big they are. If they are inaccessible and/or they are large in size, then they are corrupted for some reason.
> 
> FINALLY, please download the Canary version of chrome which contains a fix for the JumplistIcons issue, and see if it also solves your download issue. Your feedback is very important for us to better understand the bugs and our current solutions.
> 
>  Here is the link for Chrome Canary:
> https://www.google.com/chrome/browser/canary.html

Maybe some lead to follow?
Anyway some food for thoughts for all Windows developers out there willing to debug this.

-- 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/913.