GNOME Bugzilla – Bug 148205
Gimp 2.X slower in painting with Pencil Sketch brushes than Gimp 1.2.X
Last modified: 2004-12-22 21:47:04 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.
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.
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.
Can you also test with 2.1 please. And you could check whether the brush preview makes a difference or not.
I tested with 2.1 about 1 or 2 monthes ago. Same thing.
Also confirmed with 2.1 (latest CVS).This is a really dramatic slow-down.
Tested both with & without brush outline, by the way. No noticeable difference in performance.
Doesn't seem to be an issue on Win32 systems...
I was sure I'd said that... Oh look, comment #3, I did say that. :)
comment #1 I mean...
"I have tried to reproduce this with gimp 2.0.2 on Win32" is a bit older than my current CVS, though.
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...).
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.
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?
We will need profiling data here. Bumping from the 2.2 milestone since it shouldn't block the release.
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. :-(
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.
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.
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.
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.
Have you ever tried to disable perfect-mouse in your gimprc? IIRC we changed the default from no to yes for GIMP 2.0.
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.
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).
Setting milestone to 2.2 to make it show up in the list of bugs fixed for 2.2.