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 675900 - On certain images the speed is orders of magnitude slower than previous version
On certain images the speed is orders of magnitude slower than previous version
Status: RESOLVED DUPLICATE of bug 645345
Product: GIMP
Classification: Other
Component: General
2.8.0
Other Windows
: Normal major
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks: 676309
 
 
Reported: 2012-05-11 19:15 UTC by garognak
Modified: 2012-05-19 10:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description garognak 2012-05-11 19:15:17 UTC
Environment: 
Windows 7 Pro 64.
Core i7 2600K @~4.2 Ghz 8 Gb Ram.
Gimp 2.8 (about box only says 2.8) the installer was downloaded today (may 11).

Issue:
When opening certain images (for instance todays featured wp image:
http://upload.wikimedia.org/wikipedia/commons/3/39/Koppelpoort_Amersfoort_Cropped.jpg)
The following behaviour appears:

All manipulations of the image are slow. As in rendering Gimp nearly useless.
In comparison with Gimp 2.6.4, which I run in portable mode on the same PC, the 
new version achieves far less than 1/10th of the speed when, for instance, 
I am using a drawing tool. My estimate is that it is likely less than 1% 
of the speed of what 2.6.4.

It almost seems that it is the actual presentation of the image that lags. 
As soon as I attempt to draw or manipulate something I get an enormous 
delay between what I do and the result I expect to see. Using a filter does 
not seem to be much slower than before, however the updated image is drawn
gradually one block at a time on screen at a very low pace.
Gimp also causes a huge CPU spike when it attempts to update the image even 
when doing simple things like flipping it upside down.

This does not happen on all images and the problem depends on whether I open
the image or if I, for instance, copy it from the clipboard so it is a rather 
odd behaviour. In the instances where I have made a clipboard copy it always
seems to work fine.

To reproduce:
Save the image file indicated above to disk. Open it and try to draw on it.
Compare this to opening the image in a browser and copying it to clipboard 
and then pasting it in Gimp. The latter should cause no slow behaviour.


Best regards
Comment 1 Michael Schumacher 2012-05-11 20:04:43 UTC
Is this the known problem with color management?
Comment 2 garognak 2012-05-13 11:54:38 UTC
It appears so, yes.
I have looked at a few of the bugs related to colour management and the 
behaviour of Gimp appears to be similar.
As I have indicated this problem appears to also be related to what files I open.

When I open a specific file I get the slow behaviour but when I copy and paste
the exact same data via the clipboard the problem is not there anymore.

I have now verified that by turning colour management off the problem goes away.
Comment 3 Michael Schumacher 2012-05-19 10:28:11 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 645345 ***