After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 491512 - The GTK Filechooser is much to slow on a larger amount of files
The GTK Filechooser is much to slow on a larger amount of files
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.12.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
filechooser-retest-and-triage
: 473829 553187 572617 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-29 20:34 UTC by Ulf
Modified: 2018-05-02 14:30 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Description Ulf 2007-10-29 20:34:08 UTC 
Please describe the problem:
Using the Filechooser on a directory with approx 15000+ images causes the Dialog not to respond for more than 2 minutes!! 

Steps to reproduce:
1. Use THE GIMP as reference
2. point the poit the "Open File" Filechooser to a dir with 15000+ images
3. sit back and wait....


Actual results:
I have to wait ...

Expected results:
The response time could be around one second... (that's the time if I read the dir by myself and put the files in a Listview...)

Does this happen every time?
yes

Other information:
Comment 1 Emmanuele Bassi (:ebassi) 2007-10-29 21:07:24 UTC 
obviously, the file chooser is not simply listing the files, so you cannot reasonably expect the file chooser to come up in just one second in a folder with 15k images. avoiding any unresponsiveness of the UI would be the goal here.

since I guess the Gimp is displaying only images, I guesstimate that the bottleneck is the filtering code, but I would really like a profile. can you grab oprofile+oprofileui, or sysprof, run a test which only displays the 15k folder and filters for images MIME types for ten/twenty times and see where the time is spent? thanks.
Comment 2 A. Walton 2008-09-21 23:28:44 UTC 
*** Bug 553187 has been marked as a duplicate of this bug. ***
Comment 3 Timothy Arceri 2013-05-31 01:43:24 UTC 
*** Bug 572617 has been marked as a duplicate of this bug. ***
Comment 4 Timothy Arceri 2013-06-27 11:56:27 UTC 
*** Bug 473829 has been marked as a duplicate of this bug. ***
Comment 5 Miriam Mayer 2017-06-11 14:13:39 UTC 
I have the same problem when saving jpg-files into a folder containing 30K+ jpg-files using Chromium there is a six-second delay where the Chromium GUI is unresponsive. When saving to folders that only contain about 6K jpg's there's no problem and everything is as snappy as always.
Since the same behavior occurs with Firefox, I'm thinking it might have something to do with the FileChooser.
Comment 6 GNOME Infrastructure Team 2018-05-02 14:30:09 UTC 
-- 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/gtk/issues/285.