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 527644 - Generation of file list slow on second use of file-chooser dialog
Generation of file list slow on second use of file-chooser dialog
Status: RESOLVED INVALID
Product: GIMP
Classification: Other
Component: User Interface
2.4.x
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2008-04-12 01:46 UTC by Norm Murray
Modified: 2008-10-30 20:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Norm Murray 2008-04-12 01:46:47 UTC
Please describe the problem:
When doing a 'save as' operation on a file in a directory containing several hundred to 2000 images, the amount of time for the dialog to display filenames and allow editing of the current filename can take up to about 30 seconds. 

Interestingly, it's not all the time as sometimes the display is nigh immediate as expected. 

Steps to reproduce:
Open an image from a directory that contains say 2000 images (each a JPG format, sized 4000x3000 pixels or thereabouts). 'Save as' an xcf file (the first save as seems to be fine). Do some editing, do another 'save as' operation to rename, this and all subsequent 'save as' seem to take a substantial amount of time. 

Actual results:


Expected results:


Does this happen every time?
It's pretty reproducible, but not quite 100% in any given operation. It 'feels' like the first save as after opening an image (I often control-1 to open the last variant saved so that I can flatten it and sharpen that version) seems to generate the file list at a normal speed, but that subsequent save as operations are slower. 

Other information:
My overall workflow is to generate several different image variants as I edit, saving as different xcf filenames, flattening each back to a single layer, before sharpening each variant and saving as a jpg. There might be a component to this performance issue which relies upon having several multi-layered xcf.bz2 files in the directory as well, but it seems to reproduce with only the jpgs as well. 

I've tried to change the dialog preference from displaying images to displaying files, but that doesn't persist at all.
Comment 1 Sven Neumann 2008-04-14 07:02:16 UTC
You filed this to the wrong product. I can reassign this bug report for you, but not unless you tell us what operating system you are using and which version of GTK+ (and other libraries involved).
Comment 2 Norm Murray 2008-04-20 08:36:52 UTC
gtk2-2.11.6-5
gtk+-1.2.10-58

As for the rest, it would be helpful if you'd let me know which of the multitude of libs gimp is linked against you'd like versions of. 
Comment 3 Michael Schumacher 2008-04-20 08:51:01 UTC
Interesting. You're using an unstable version of GTK+?
Comment 4 Norm Murray 2008-04-20 08:53:35 UTC
System is otherwise been quite happy for several months, think early F8 install. I'll get around to rebuilding eventually, but this is the single pain point. 
Comment 5 Sven Neumann 2008-04-21 13:03:21 UTC
We don't support unstable development versions of GTK+. Closing as INVALID.