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 148205 - Gimp 2.X slower in painting with Pencil Sketch brushes than Gimp 1.2.X
Gimp 2.X slower in painting with Pencil Sketch brushes than Gimp 1.2.X
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
unspecified
Other Linux
: Normal normal
: 2.2
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2004-07-22 20:06 UTC by Richard Van Den Boom
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Richard Van Den Boom 2004-07-22 20:06:11 UTC
Just create a new image (reasonable size) in Gimp 2.X, select the large Pencil 
Sketch brush then draw on the image with a mouse or tablet with quick stroke 
back and forth, like if you were coloring with a pen. On two Athlon xp 1600 
and 1700 I tried, at some point, the system seems not to keep up and the 
cursor increasingly lags behind the mouse/tablet. If you stop drawing, the 
cursor still keeps moving for a few seconds to finish the movement. 
Starting Gimp 1.2.X, doing the same, I never experience any lag. 
 
I don't know if it's a Gimp 2 or GTK2 issue but it makes Gimp definitely 
unusable on my systems, which may not be the fastest in the world but should 
be plenty enough to get good results. Well, we do get them with Gimp 1.2.X.  
 
Note that I run Gimp on KDE 3.2.X on a Slackware 10 systems. Both systems have 
256MB of memory, which is a bit too short, but they are not overloaded. And 
again, Gimp 1.2.X works well on both.
Comment 1 Dave Neary 2004-07-23 10:23:51 UTC
Sven, 

how is a speed regression considered an enhancement request? I don't understand
the severity change, particularly since it came without a confirmation.

Richard, I have tried to reproduce this with gimp 2.0.2 on Win32, and have been
unable to do so (on a machine a lot slower than yours). I have also tried on a
very slow Linux machine, and there was a significant slow-down. So this looks
like a problem on Linux only, and it's a problem with other animated brushes too
(I also tried with the sparks, vine and felt pen brushes).

Confirming, and setting severity a little higher.

Dave.


Cheers,
Dave.
Comment 2 weskaggs 2004-07-23 17:45:52 UTC
I can also see the painting fall behind even on a rather fast Linux machine. 
Interestingly, it looks like it falls a lot farther behind for the 16x16 pencil
sketch brush than for the 64x64 brush.
Comment 3 Sven Neumann 2004-07-23 18:06:31 UTC
Can you also test with 2.1 please. And you could check whether the brush preview
makes a difference or not.
Comment 4 Richard Van Den Boom 2004-07-23 20:10:46 UTC
I tested with 2.1 about 1 or 2 monthes ago. Same thing. 
Comment 5 Dave Neary 2004-07-23 20:24:52 UTC
Also confirmed with 2.1 (latest CVS).This is a really dramatic slow-down.
Comment 6 Dave Neary 2004-07-23 20:38:40 UTC
Tested both with & without brush outline, by the way. No noticeable difference
in performance.
Comment 7 Michael Schumacher 2004-07-23 21:10:16 UTC
Doesn't seem to be an issue on Win32 systems...
Comment 8 Dave Neary 2004-07-23 21:23:34 UTC
I was sure I'd said that... Oh look, comment #3, I did say that. :)
Comment 9 Dave Neary 2004-07-23 21:24:29 UTC
comment #1 I mean...
Comment 10 Michael Schumacher 2004-07-23 21:36:25 UTC
"I have tried to reproduce this with gimp 2.0.2 on Win32"

is a bit older than my current CVS, though.
Comment 11 Michael Natterer 2004-07-24 14:22:41 UTC
I am absolutely unable to reproduce this.
GIMP 2.1 paints just as fast as 1.2.x here.

(tried with both the paintbrush and the pencil with both the 16x16 and
64x64 sketch brushes on a 1000x1000 layer with and without alpha)

Apparently the observed behavior is a side effect of something else,
and not a significant slowdown of the actual painting and display
rendering process itself.

Perhaps someone who can reproduce it can build GIMP with profiling
support and check where all the CPU cycles go (given it still
occurs then...).
Comment 12 Raphaël Quinet 2004-07-25 11:44:09 UTC
Interesting...  I tried to reproduce this bug on my Athlon 2400+ and at first I
thought that there were no problems.  I tried with "Vine", "Sparks", "Galaxy"
and "Pencil Sketch #2" (64x64) and everything was fine.  But then I tried with
the smaller brush "Pencil Sketch" (16x16) and I quickly saw the brush strokes
lagging behind.  With the 30x30 or 32x32 brushes, the lag is less visible but
shows up after a while.

So it looks like this problem occurs mostly with small animated brushes or is
less severe when the brush gets bigger.  The bug doesn't seem to occur for
non-animated brushes and the following parameters do not affect it: alpha,
image mode (RGB, grayscale or indexed), brush mode, opacity, usage of gradients
or other fancy tool options, image zoom level, whether the brush outline is
shown or not, cursor rendering, usage of mouse or extended input device, ...
I also tried with and without the motion history patch supplied by Mitch,
without any visible difference (besides hundreds of debug messages all saying
"1 events in device history").

I tried to change most of the parameters that could affect this bug and the only
one that seems to matter is the size of the animated brush.
Comment 13 Pedro Gimeno 2004-07-25 14:29:54 UTC
I could reproduce it with non-animated brushes as well. Apparently the spacing
is very important. A slow X server (e.g. VNC, maybe Xnest) allows to easily
reproduce the problem. This leads me to a first conjecture: might it be caused
by too many unnecessary expose events?
Comment 14 Sven Neumann 2004-10-04 09:12:48 UTC
We will need profiling data here. Bumping from the 2.2 milestone since it
shouldn't block the release.
Comment 15 Richard Van Den Boom 2004-10-26 06:14:58 UTC
I can build a gimp with specific options and run any test you want, if you 
give me precise enough indications. I'm not used to debugging/profiling tools 
and don't know much about them. 
I'd be very interested having this fixed or understood (it may be an X-related 
issue, since apparently, the problem also occur on Gimp for MacOSX), since GAP 
has very nice additions in the 2.X releases but I cannot use them because of 
this drawing issue. 
Just tell me what to do. 
BTW, I have now an Opteron 2GHz with Gimp 2.1.7 and X.org 6.8.1 and the 
problem is still there. :-( 
Comment 16 Sven Neumann 2004-10-26 13:09:00 UTC
Well, we don't have an idea what's going wrong and I at least have not been able
to reproduce your problem. So I don't know what you could do except debugging
the problem yourself and show us where exactly GIMP is spending it's time.
Comment 17 Richard Van Den Boom 2004-10-26 13:54:50 UTC
I think you've been downplaying this problem a  bit from the beginning. 
I'm not a programmer. Debugging is not something I know how to do. The issue 
was easily reproduced by many people here apparently, and it seems that it's 
related to Linux and MacOSX, not to Windows, so my guess is that it has 
something to do with interaction between X11 and Gimp. 
On what system have you tried it? It's the first time you actually claim not 
being able to reproduce it. Maybe showing your system will help seeing the 
differences with mine's and the others?  
As I said, I can run any test you want, I'm just not able to figure out what 
kind of tools can be useful, whether it's Oprofile, Gprof, whether you need to 
compile gimp, gtk or anything else with debug option, etc. I know of these 
tools but I don't know how to use them and I certainly don't know what would be 
the most useful for you guys. 
Please provide me with some instructions on what type of tests and data you 
need, and I'll be happy to test them and to send you anything I can.  
I just checked it again on a Asus laptop with a Athlon64 3000+ : created a new 
RGB 1280x720 image, select the PencilSketch#2, draw back and forth quickly and 
see Gimp CPU usage reach 99% almost instantly while the drawing lags far behind 
the mouse.  
I've just tested it on a SuSE 9.1 with stock Gimp 2.0 and bingo, it occurs 
again.  
Comment 18 Sven Neumann 2004-10-26 14:05:38 UTC
The title of this bug report claims that GIMP 2.0 would be slower in painting
than GIMP 1.2. That alone is not a problem. GIMP 2.0 does more than 1.2 so it
isn't surprising if it is slightly slower. I don't receive this as a problem
since the drawing speed is still reasonable and doesn't keep me from using the
sketch brush.
I don't really see what point you are trying to make here.
Comment 19 Richard Van Den Boom 2004-10-26 14:40:08 UTC
You probably never draw sketches by yourself using Gimp then. 
It is not **slightly** slower. After ten quick strokes back and forth, Gimp is 
still drawing left to right while your hand is drawing right to left. For an 
artist, it is not possible to draw something properly if the pointer in the 
image does not follow the mouse perfectly. The drawing speed may be reasonable 
for you and it is if you just make one short stroke, but that's not how all 
artists work. And when drawing quickly, the delays become unbearable. Gimp2.X 
is slower at painting and it **is** a problem because it makes it unusable to 
draw drawings like these : http://svdboom.free.fr. 
I've just try to run Gimp using valgrind / cachegrind hoping to find some 
useful profiling for you : when in the image, the pointer does not even manage 
to follow the mouse, even when not drawing at all, just moving the mouse. Yes, 
valgrind takes a lot of ressources but it seems to me that just having the Gimp 
cursor follow the mouse should be OK on an A64 3000. 
Are you or anybody else interested in the valgrind output? It's still 1.1MB in 
tar.bz2 so I don't expect it to be accepted as an attachment here.  
It's just a stupid "callgrind gimp" output so if you need other options, let me 
know. 
Comment 20 Sven Neumann 2004-10-26 15:00:46 UTC
Have you ever tried to disable perfect-mouse in your gimprc? IIRC we changed the
default from no to yes for GIMP 2.0.
Comment 21 Richard Van Den Boom 2004-10-26 15:29:33 UTC
I had tried before but for the sake of it, I retried with my current 2.1.7 
Gimp. Unfortunately, it doesn't change anything.  
According to your man page, this option turned on should make big brushes 
slower, but it's actually with smaller brushes that the effect seems more 
pronounced. 
I confirm that the problem does not occur on Windows though. Just tested on 
Windows 2003 with Gimp 2.0. 
 
Just to make things clear, I perfectly understand that with the 2.2 release, 
Gimp devs have better things to do than to fix this. I don't want to rush 
anyone since I know you all work on this during your spare time and what you've 
done is a great accomplishment. I perfectly understand that you want to 
postpone fixing this to a later date, I just want to make sure you do not 
downplay this problem and decide it does not need to be fixed at all at some 
point.  
Comment 22 weskaggs 2004-12-09 21:43:31 UTC
This problem can easily be seen if you paint with any animated brush with the
spacing set to 1.  It turns out that the delay is caused by creating a new
random number generator every time gimp_brush_pipe_select_brush() is called. 
(Which doesn't make sense, anyway.)  I got rid of this, and changed a call to
g_rand_int_range() into g_random_int_range(), which automatically takes care of
creating and initilizing the random number generator if necessary.  It looks
like small animated brushes now keep up as well as ordinary brushes, at least on
my system.  I'll call this FIXED; please reopen if there are still problems.

 2004-12-09  Bill Skaggs <weskaggs@primate.ucdavis.edu>

	* app/core/gimpbrushpipe.c (gimp_brush_pipe_select_brush):
	Don't initialize a new random number generator every time a brush
	is selected from a pipe.  Fixes bug #148205).
Comment 23 Sven Neumann 2004-12-09 23:33:42 UTC
Setting milestone to 2.2 to make it show up in the list of bugs fixed for 2.2.