GNOME Bugzilla – Bug 789355
Gtk::FileChooserButton performance on Windows
Last modified: 2018-05-22 12:19:20 UTC
Created attachment 362111 [details] minimal example Hello, I'm a developer of RawTherapee (http://rawtherapee.com), which is based on gtkmm 3. One user has recently reported very slow startup times on Windows 10. After a series of emails, he has been able to reproduce the issue on a very small program that uses only gtkmm (that is, no rawtherapee involved at all). According to the user, it takes about 7 seconds to show the window on his win10 machine, under normal circumstances. But occasionally this takes up to 40-50 seconds. I have only a win7 VM (don't use windows normally) and could not reproduce the issue myself, but I still hope this could be of some use. FYI, the original report and the follow-up conversation are online: https://discuss.pixls.us/t/rawtherapee-5-3-released
The first comment with a minimal code sample is: https://discuss.pixls.us/t/rawtherapee-5-3-released/5226/105
Since gtkmm just wraps GTK+ for all non-trivial/-convenience functionality, this will almost certainly be an issue on GTK+'s side, not gtkmm. On a quick search I couldn't find a bug there for slowness in the FC on Windows. Are you able to excerpt the relevant details about the affected user's system here? Not exhaustive but I'm thinking OS/architecture, number/types of online drives, approximate number of files, etc.? That thread is gigantic and could take a long time for anyone else to parse the relevant few details from, but hopefully you already did that. :)
Hi, unfortunately I do not have much more info myself. From what I understood, it is known that you can get stuck waiting when accessing volumes/drives (don't remember the exact terminology) on windows under certain conditions. Since apparently GTK+ creates the file dialog when building the file selection button, I suspect it just hits one of these cases. In RawTherapee, we have worked around this by implementing our custom file chooser button (with the subset of functionalities that we are actually using) that creates the file selection dialog only on-demand, when the button gets clicked. In this way, we at least avoid paying the price of waiting when the file dialog is not needed (which is 99% of the time typically...). HTH
-- 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/gtkmm/issues/27.