Gimp causes 100% processor load
Frantisek Fuka
I run Gimp 2.2 package on Debian Sarge and I have the following
problem:
I select "Paint" or "Draw" or "Erase" or something similar and then I
use the tool continuously (without releasing mouse button) e.g. for 10
seconds. The display updates correctly but processor load is at 100%.
The worst happens when I release the button. The processor load stays
at 100% (of which roughly 50-60% is XFree86, 30% is Gimp) for at least
another 10 seconds and during this time the whole computer is
completely unresponsible (mouse pointer moves but does not register
clicks - thay all get registered only after those 10 seconds).
The exactly same thing happened with Gimp 2.1. I waited for Gimp 2.2
(because I don't use freehand drawing/erasing very much) but it keeps
happening even with 2.2.
I have Fingerworks Mini and Wacom Tablet but the exact same problem
appears when I disconnect both and use standard USB mouse.
Thanks for any ideas.
Roy Schestowitz
The problem is indeed strange. I have a similar problem with Firefox (SuSE
8.2), wherein I suspect that the cause might be plug-in collisions. In
fact, many plug-ins (extensions) are known to intervene with each other and
cause problems under certain circumstances. Much like you say, I have
Firefox surging to ~70% and the rest is devoured by X.
So, I suppose my point would be: are you installing some additional software
or plug-ins to the GIMP? Have you tried installing GIMP 1.2 to see if that
makes a difference? A live CD? The behaviour is really difficult to debug.
Regressing which discovers a state/s which still work/s helps in
identifying the source of the problem.
Are you forced to quit the GIMP after that obscene CPU load? Does the
problem fix itself? In my case, I get 'warning signs' before the CPU usage
climbs on and on. So, I have plenty of time to save my work and then quit
(restart). It is a pain due to tabbed browsing and I am sure it is too when
you have palettes, layers and multiple images open.
Hope it helps,
Roy
--
Roy S. Schestowitz | Open the Gate$ to Hell
http://Schestowitz.com | SuSE Linux | PGP-Key: 74572E8E
4:55am up 25 days 17:09, 3 users, load average: 1.12, 1.02, 0.91
Jim Sabatke
Your Firefox problem is probably due to memory leaks, which the Mozilla
team has been trying to kill for years. I have the same problem and I
don't use many plugins.
As far as gimp: excessive swapping could be the problem. Try running
"free" from a command line and see how much is being swapped (I'm
assuming Linux here).
Good luck,
Jim
Frantisek Fuka
any plugins or modifications whatsoever. There is absolutely no
swapping, I have hundreds of MBs of free memory when this happens
(768MB total). The system is always unresponsive for those 10 seconds
and then everything works again - and all events I clicked or dragged
during those 10 seconds are carried out immediately after the "locking"
ends.
Heinrich Woick
> I select "Paint" or "Draw" or "Erase" or something similar and then I
> use the tool continuously (without releasing mouse button) e.g. for 10
> seconds. The display updates correctly but processor load is at 100%.
> The worst happens when I release the button. The processor load stays
> at 100% (of which roughly 50-60% is XFree86, 30% is Gimp) for at least
I faintly remember a discussion where this was attributed to the Undo
function which seems to cause a high workload on the processor in such
situations as you describe.
Is Undo enabled? Unfortunately, I cannot find how to disable it for
testing. It seems that you can enable Undo only at install time.
Heinrich
Roy Schestowitz
It sound like the exact same symptoms I have noticed with Firefox:
-No effect on memory
-All actions eventually done, but very slowly so
-Slow-down is gradual, but nearly a /halt/ is reached rather quickly (within
seconds), which then exacerbates significantly.
__/ [Jim Sabatke] on Tuesday 20 September 2005 17:00 \__
> Your Firefox problem is probably due to memory leaks, which the Mozilla
> team has been trying to kill for years. I have the same problem and I
> don't use many plugins.
I would have to doubt it. I always have my system monitor at the top and
jusdging by the memory bar, there is no leak. No memory appears to have
leaked in nearly a month of uptime with heavy Firefox use.
> As far as gimp: excessive swapping could be the problem. Try running
> "free" from a command line and see how much is being swapped (I'm
> assuming Linux here).
>
> Good luck,
>
> Jim
Good suggestion. I think it might be easier to avoid continuous mouse
pressing (see below).
__/ [Heinrich Woick] on Tuesday 20 September 2005 22:09 \__
> I faintly remember a discussion where this was attributed to the Undo
> function which seems to cause a high workload on the processor in such
> situations as you describe.
>
> Is Undo enabled? Unfortunately, I cannot find how to disable it for
> testing. It seems that you can enable Undo only at install time.
>
> Heinrich
The above appears to make sense to me, _but_...
Undo should not keep track of continuous strokes. Once a stroke is undone,
it is undone entirely[1]. This, in fact, is why I often prefer many small
stroke to one persistent stroke -- the undo stack. There are exceptions,
however, e.g.:
- fuzzy selections where letting the button go immediately leads to a
selection being made.
- Bezier curves and the like.
Roy
[1] Then again, I use GIMP 1.2.x (I have 2.x on 2 other Ubuntu machines, but
the menus have me disorientated)
--
Roy S. Schestowitz | Useful fact: close elevator button = Express Mode
http://Schestowitz.com | SuSE Linux | PGP-Key: 74572E8E
4:25am up 26 days 16:39, 3 users, load average: 0.19, 0.55, 0.67
Jim Sabatke
> __/ [Jim Sabatke] on Tuesday 20 September 2005 17:00 \__
>
>
>>Your Firefox problem is probably due to memory leaks, which the Mozilla
>>team has been trying to kill for years. I have the same problem and I
>>don't use many plugins.
>
>
>
> I would have to doubt it. I always have my system monitor at the top and
> jusdging by the memory bar, there is no leak. No memory appears to have
> leaked in nearly a month of uptime with heavy Firefox use.
I have noticed that my machines with 256 MB memory (SuSE 9.0) have the
firefox slowdown problem after 2-3 days of heavy use. My machines with
more memory don't seem to have the same problem.
I'm wondering if others have seen this.
Sorry for hijacking this thread, but I'm following another comment and
it is memory use related.
Jim
Per Larsen
In File/Preferences you can change 'Minimal number of undo levels' and 'Maximum undo memory' in the 'Environment'. Maybe that will help?
PerL
Frantisek Fuka
tool, then place the mousepointer on the canvas and keep holding the
mousebutton, without moving the mouse. A blob appears, the processor
load stays low, everything is OK. Then, while still holding the
mousebutton, I move the pointer for, say, 5 seconds. Processor load
immediately jumps to 100% and stays there for 5 more seconds after I
finish moving the mouse. The interesting thing is that even when the
system load is 100%, the drawing works and tool responds as it should.
The problem comes when I release the mousebutton during this "100%
overload". Because until the "overload" ends (it always lasts about as
long as my last burst of drawing), GIMP (or rather the whole system) is
totally unresponsive. I cannot start drawing another stroke or do
anything else until "overload" ends, at which time all my strokes I
made during the "overload" are instantly drawn.
Changing Undo or cache options has absolutely no effect on this.
Also, I use Firefox all the time and never encountered anything similar.
Heinrich Woick
> In File/Preferences you can change 'Minimal number of undo levels' and
> 'Maximum undo memory' in the 'Environment'. Maybe that will help?
Actually, yes. With this hint, I cannot find any difference between
performances neither with numbers set to zero nor with high numbers. In
both cases, it takes no more than two seconds to have Gimp come back to
rest after releasing the left mouse button.
Well, this is what I observed with the task manager update speed set to
medium. When I set it to "high", the settling of Gimp appears much
faster, i.e. less than a second.
My system is Win XP, Gimp 2.2.8, with Seamonkey (former Mozilla Suite)
active. CPU is a 1.6 GHz Pentium 4 with built-in graphics.
Heinrich
Frantisek Fuka
When I disable it, Gimp works fine. I'll contact the author.
kyl...@gmail.com
operations. After making modifications to an image, I do a "Save As",
which works perfectly fine. But if I then make more mods to the same
image (like make a custom thumbnail from it), and then do "Save As"
again to save the thumbnail, the "Save As" dialog will hang, pegging
the CPU for up to 10 seconds (longer if I do more Save As operations)
before returning to normal and allowing me to continue.
This was NOT a problem with previous versions of the Gimp. Any ideas
or workarounds for this issue??? It only occurs on the second and
subsequent "Save As" operations.