Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Gimp causes 100% processor load

  • Subject: Re: Gimp causes 100% processor load
  • From: Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx>
  • Date: Wed, 21 Sep 2005 04:41:25 +0100
  • Newsgroups: comp.graphics.apps.gimp
  • Organization: schestowitz.com / MCC / Manchester University
  • References: <1127154684.088052.239870@z14g2000cwz.googlegroups.com> <dgo1s8$3t$1@godfrey.mcc.ac.uk> <1127233686.122460.195510@g44g2000cwa.googlegroups.com>
  • Reply-to: newsgroups@xxxxxxxxxxxxxxx
  • User-agent: KNode/0.7.2
__/ [Frantisek  Fuka] on Tuesday 20 September 2005 17:28 \__

> I use vanilla gimp Debian package installed through aptitude, without
> 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.

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.


[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

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index