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 675546 - gimp 2.8 very slow panning
gimp 2.8 very slow panning
Status: RESOLVED DUPLICATE of bug 674928
Product: GIMP
Classification: Other
Component: User Interface
2.8.0
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 676780 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-05-06 04:40 UTC by psycommando
Modified: 2012-08-30 07:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description psycommando 2012-05-06 04:40:43 UTC
Hello, I saw a similar bug for 2.6.12, and commented there, but I guess it must have fallen out of view because its set for version 2.6. If not, then nevermind.

When using the gimp 2.8.0 and panning the image, it gets extremely slow and even makes gimp completely unresponsive for a few seconds. it does that at every zoom levels, with a big or small image. I use the default settings.

My computer is more than capable of running the gimp:
- AMD Phenom 2 X4
- 8GB ram
- Nvidia GTS450 
- 1TB HDD with 8GB free
Comment 1 Uwe Kadritzke 2012-05-08 13:01:56 UTC
Gimp 2.8.0 on a 6 month old Acer Notebook, AMD C-50, 4GB RAM, Windows 7 is so slow, it's almost unusable. Simple Tools like Selection, Crop, or simple filters like Desaturate almost freeze the system. Even moving the mouse over an image window without clicking anything triggers the processor clock scaling up. 

Fiddling with Preferences-Environment haven't helped so far. 

None of these effects ever appeared with 2.6.12. 



A word to the report above:
---
My computer is more than capable of running the gimp: 
[...]
- 1TB HDD with 8GB free
---

If there is really only 8GB left on a 1TB HD, then this could lead to severe swap file problems, especially with Windows. Linux ususally swaps to a swap partition, but Gimp keeps a cache in the home folder; see Edit-Preferences-Folders: Swap Folder. 

Unfortunately, we don't know the OS. psycommando, if you read this, you might want to add your OS.
Comment 2 Alain Cabiran 2012-05-08 13:33:40 UTC
Gimp 2.8.0 has same problem here on a Core 2 E8750 with :

- Windows 7 x64, 8GiB ram, 127GiB hdd partition with 37GiB free
- Virtualbox with Windows XP 32 Bits, 2GiB ram allocated, quite empty partition (32 GiB dynamic on 2nd hdd with only windows, drivers and vbox additions, i only use it for testing purposes).

Gimp 2.6.11 w32 runs fine with same xcf 1Gib image.

Problems seems to come from "draw methods" : internal treatments seems to run fine but when it comes to draw something on screen, even scrolling or resizing picture window is a pain.

Gimp 2.6.11 is many times faster when interacting with screen.

It even tried with a 120MiB image which is ridiculous regarding nowadays digital camera pictures.

regards
Comment 3 Michael Schumacher 2012-05-08 13:38:42 UTC
Is this the color management problem, i.e. does the slowness go away if you disable the color management display filter in GIMP?
Comment 4 Alain Cabiran 2012-05-08 13:47:02 UTC
Reinstall.... test.... No, same problem.. why scrollbars drawing is slow ? strange.. maybe without "native dll" option... i try
Comment 5 Alain Cabiran 2012-05-08 13:53:42 UTC
(In reply to comment #4)
> Reinstall.... test.... No, same problem.. why scrollbars drawing is slow ?
> strange.. maybe without "native dll" option... i try

Same problem with compact installation.
Comment 6 Michael Schumacher 2012-05-08 13:56:56 UTC
Just to make sure:

- reinstalling doesn't disable the color management display filter, this is a setting in GIMP's preferences
Comment 7 Alain Cabiran 2012-05-08 14:01:37 UTC
(In reply to comment #6)
> Just to make sure:
> 
> - reinstalling doesn't disable the color management display filter, this is a
> setting in GIMP's preferences

I know : i disabled cms in gimp, had slowness problem, deinstalled gimp and reinstalled with compact installation, tested and had slowness problem.
Comment 8 Uwe Kadritzke 2012-05-08 14:47:56 UTC
For anyone who wants to test Gimp reaction with/without CM:

1. Edit > Preferences > Color Management > Mode of operation: "No color management"

You should be able to keep all other settings (ICC profiles etc.) for later use, just prevent gimp to use them now.


2. View > Display Filters... > Active Filters: Remove Color Management Filter form Active Filters

I'm not sure about this new feature, but disable it anyway.
Comment 9 Alain Cabiran 2012-05-08 15:05:45 UTC
(In reply to comment #8)
> For anyone who wants to test Gimp reaction with/without CM:
> 
> 1. Edit > Preferences > Color Management > Mode of operation: "No color
> management"
> 
> You should be able to keep all other settings (ICC profiles etc.) for later
> use, just prevent gimp to use them now.
> 
> 
> 2. View > Display Filters... > Active Filters: Remove Color Management Filter
> form Active Filters
> 
> I'm not sure about this new feature, but disable it anyway.

I didn't know "2", but have the same problem :'(

deactivating each point seems to improve things a very little bit but i'm not sure.

I tried something unvoluntarily : i have a program that deactivate aero. this time the drawing speed improved.. don't ask me why it's faster, i just noticed that ^_^.
Comment 10 Alain Cabiran 2012-05-08 15:38:37 UTC
Oups, just in case, my computer has a nvidia gtx260 with 896mib vram so it's not a video performance problem.
Comment 11 Alain Cabiran 2012-05-08 16:14:26 UTC
The simplest test to see how horrible it is :
create an empty 640x480 image
use your middle mouse boutton to do what follows :
move the picture without hitting window borders -> everything works fine
put a little part of the image outside viewport
try to get it back entirely visible...

i've put a screen capture on facebook
Comment 12 psycommando 2012-05-08 19:10:00 UTC
(In reply to comment #1)
> Gimp 2.8.0 on a 6 month old Acer Notebook, AMD C-50, 4GB RAM, Windows 7 is so
> slow, it's almost unusable. Simple Tools like Selection, Crop, or simple
> filters like Desaturate almost freeze the system. Even moving the mouse over an
> image window without clicking anything triggers the processor clock scaling up. 
> 
> Fiddling with Preferences-Environment haven't helped so far. 
> 
> None of these effects ever appeared with 2.6.12. 
> 
> 
> 
> A word to the report above:
> ---
> My computer is more than capable of running the gimp: 
> [...]
> - 1TB HDD with 8GB free
> ---
> 
> If there is really only 8GB left on a 1TB HD, then this could lead to severe
> swap file problems, especially with Windows. Linux ususally swaps to a swap
> partition, but Gimp keeps a cache in the home folder; see
> Edit-Preferences-Folders: Swap Folder. 
> 
> Unfortunately, we don't know the OS. psycommando, if you read this, you might
> want to add your OS.

Woops, sorry, my OS is windows 7 64 bits. 

I doubt I would have much swapping problem, since I set my swap to a constant static size, disabling dynamic swap size management. Besides I was using a really tiny image for my tests a 640x480 blank image.

I also heard of the trick to disable the color management, but it only marginally improved the speed.
Comment 13 Lyle Kroll 2012-05-10 23:12:59 UTC
Yes, disabling color management eliminates the lag issue (at least for me), but, this is really unacceptable since I do like an image with an embedded color profile to automatically be converted to sRGB (this ability no longer is automatic when you disable color management).   Could enable, open image, then disable, but his is not a desireable workflow either.   Heard many complaints from GIMPUsers, to GIMPChat.   Still, overall, I have to say, I'm happy with GIMP 2.8 despite the idiosyncrasies since now I haw a truly working 64-bit GIMP for Windows.    :)
Comment 14 Alain Cabiran 2012-05-11 16:45:33 UTC
(In reply to comment #13)
> Yes, disabling color management eliminates the lag issue (at least for me),
> but, this is really unacceptable since I do like an image with an embedded
> color profile to automatically be converted to sRGB (this ability no longer is
> automatic when you disable color management).   Could enable, open image, then
> disable, but his is not a desireable workflow either.   Heard many complaints
> from GIMPUsers, to GIMPChat.   Still, overall, I have to say, I'm happy with
> GIMP 2.8 despite the idiosyncrasies since now I haw a truly working 64-bit GIMP
> for Windows.    :)

I'm interested in your configuration, did you install standalone 64bits gtk+ before gimp ? did you have mingw installed ? 

if "drawing tools" become quite confortable (but slower than w32 2.6.11 on my system) scrolling is still unuseable/horrible. If moving image (larger that your screen with zoom or not) is not lagging for you, i'd like to reproduce it here to see what's happening.

regards,

notes: i installed an ubuntu 12.04 with gimp 2.8 update in a vbox, its speed seems to be identical to the 2.6 on an older ubuntu i also have in vbox. so scrolling/drawing/(color ?) lag seems to be Windows(32/64) specific.
Comment 15 Alain Cabiran 2012-05-11 17:02:08 UTC
LOL i've found a part of the problem : very funny for a "from linux" software i used a long time in this o.s. : gimp 2.8 is much faster when running as admin. :s

disabling color management, disabling aero, and *running as admin*, gimp becomes quite useable (but much slower than the 2.6.11 i have)
Comment 16 Lyle Kroll 2012-05-11 17:42:00 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > Yes, disabling color management eliminates the lag issue (at least for me),
> > but, this is really unacceptable since I do like an image with an embedded
> > color profile to automatically be converted to sRGB (this ability no longer is
> > automatic when you disable color management).   Could enable, open image, then
> > disable, but his is not a desireable workflow either.   Heard many complaints
> > from GIMPUsers, to GIMPChat.   Still, overall, I have to say, I'm happy with
> > GIMP 2.8 despite the idiosyncrasies since now I haw a truly working 64-bit GIMP
> > for Windows.    :)
> I'm interested in your configuration, did you install standalone 64bits gtk+
> before gimp ? did you have mingw installed ? 
> if "drawing tools" become quite confortable (but slower than w32 2.6.11 on my
> system) scrolling is still unuseable/horrible. If moving image (larger that
> your screen with zoom or not) is not lagging for you, i'd like to reproduce it
> here to see what's happening.
> regards,
> notes: i installed an ubuntu 12.04 with gimp 2.8 update in a vbox, its speed
> seems to be identical to the 2.6 on an older ubuntu i also have in vbox. so
> scrolling/drawing/(color ?) lag seems to be Windows(32/64) specific.

Just a medium long (since 1.2.x) time user of GIMP; installed 64-bit Windows version from Sourceforge site (not a coder or program compiler; leave that to the gurus who are).   :)
Comment 17 Alain Cabiran 2012-05-12 15:49:56 UTC
You could have installed some ported unix tools like ls, cp rm, less, bzip2, cmp, diff, gvim... within mingw that's why i asked.

to everybody : A little video that shows the problem : http://youtu.be/iCrac2boNpg

The scrolling lag under gimp 2.8 can be as long as 10 seconds or more without giving hand and having 100% cpu used. (i forgot to put it on video).

the problem happened *before* i tried and succeeded to have twice gimp installed. nothing changed between before and after dual installation.

regards
Comment 18 Michael Schumacher 2012-05-17 22:49:00 UTC
It's hard to tell what problem this bug report is tracing - is it the same as in bug #674051?
Comment 19 psycommando 2012-05-17 23:23:14 UTC
(In reply to comment #18)
> It's hard to tell what problem this bug report is tracing - is it the same as
> in bug #674051?

Its similar, but the title is a little less ambiguous.
Comment 20 Alain Cabiran 2012-05-18 12:26:50 UTC
I agree with psycommando, this one is more precise as the problem occurs even without zooming : you can play a "don't touch borders while moving fast" with a small empty picture ^_^.

Oh i noticed that my dual core stays at 50% during "freezes" so only one core is used... Also same problem with twice windows behaviour...Pencil lag is solved just by disabling drawing/color management filter but drawing selection (rectangle for example) is still slow, floating selection (ctrl-shift-j) is also slow... Internal filters work faster...

If you think about any test which can help, don't hesitate to tell, i'll try.
Comment 21 Michael Schumacher 2012-05-24 23:09:07 UTC
*** Bug 676780 has been marked as a duplicate of this bug. ***
Comment 22 Lyle Kroll 2012-06-06 19:02:05 UTC
Onkel Hatti posted a possible fix that may work, but, it will require a complete re-compile and that is beyond me.   :)

http://gimpchat.com/viewtopic.php?f=7&t=4460
Comment 23 Isaac Wingfield 2012-06-14 05:34:50 UTC
Also having a problem with very slow response on OS X/Snow Leopard. Compared to 2.6, the movement of the grid when doing a "rotate" is so slow and sluggish as to be unusable. In 2.6 the rotation is "real time".

Disabling color management and restarting has no effect.
Comment 24 Max Mustermann 2012-08-28 20:05:42 UTC
Could the reporters problem be a duplicate of bug #674928 and problems in comment#1 and ongoing a duplicate of bug #645345?
Comment 25 Alain Cabiran 2012-08-29 00:46:23 UTC
#674928 : Yes it is, exactly the same problem. the video i made looks like his.

#645345 : Not it's not the same, it maybe worse, i made a longer video which shows an identical panning slowness problem even without plugins, with everything disabled and color management disabled too...
Comment 26 Max Mustermann 2012-08-29 18:38:21 UTC
Thank you for your report.
Alain or Bugsquad, can you please mark it as an duplicate of bug#674928? Thank you.
Comment 27 Alain Cabiran 2012-08-30 00:03:37 UTC
i'm sorry but i don't have rights on this bugs to modify its status :(
Comment 28 Michael Natterer 2012-08-30 07:24:26 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 674928 ***