GNOME Bugzilla – Bug 675546
gimp 2.8 very slow panning
Last modified: 2012-08-30 07:24:26 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
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.
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
Is this the color management problem, i.e. does the slowness go away if you disable the color management display filter in GIMP?
Reinstall.... test.... No, same problem.. why scrollbars drawing is slow ? strange.. maybe without "native dll" option... i try
(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.
Just to make sure: - reinstalling doesn't disable the color management display filter, this is a setting in GIMP's preferences
(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.
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.
(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 ^_^.
Oups, just in case, my computer has a nvidia gtx260 with 896mib vram so it's not a video performance problem.
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
(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.
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. :)
(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.
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)
(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). :)
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
It's hard to tell what problem this bug report is tracing - is it the same as in bug #674051?
(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.
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.
*** Bug 676780 has been marked as a duplicate of this bug. ***
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
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.
Could the reporters problem be a duplicate of bug #674928 and problems in comment#1 and ongoing a duplicate of bug #645345?
#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...
Thank you for your report. Alain or Bugsquad, can you please mark it as an duplicate of bug#674928? Thank you.
i'm sorry but i don't have rights on this bugs to modify its status :(
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 ***