Gimp lags and misses some strokes especially when drawing fast

Bug #41798 reported by Kristoffer Lundén
This bug affects 4 people
Affects Status Importance Assigned to Milestone
gimp (Ubuntu)
Fix Released
Ubuntu Desktop Bugs

Bug Description

When drawing in the Gimp, the cursor often lags behind, and some strokes are sometimes missing completely. This gets worse as one draws faster, up till almost unusable if trying to draw "normally".

Trying applications like Inkscape, everything is registered perfectly, no matter how fast I make lines and calligraphy.

I'm using a Wacom board, and this is not on a slow or even slowish computer, it's on a 2.4MHz with large memory, quite recent Nvidia card and accelerated drivers. No other graphics applications, including stuff like Unreal Tournament has any trouble, so I don't think that's it, and the tablet works fine in other gfx apps.

I'm not using unreasonable image sizes either, this happens and behaves mostly the same on a 72dpi 1024x768 image just as well as a 300dpi A3.

Not actually being an artist myself, but I work with a lot of them, and honestly, I can't show Gimp to any of them in this state. I don't know if this is a general Gimp issue or if it's only in Ubuntu, or even just in Dapper, since I don't have other distros to compare with. Any clues to investigate and fix, and opinions from others would be welcome.

Revision history for this message
Kristoffer Lundén (kristoffer-lunden) wrote :

Found another one with the same problem:

That description is probably better, too:

"have my Wacom Graphire 4 tablet working on Linux (Ubuntu 6.04,
kernel 2.6.15, built-in tablet drivers) and get bad pressure sensivity
and line quality in The GIMP 2.2.10, but at least it's working.

However, when using any of the paint/ink tools, although producing a
decent stroke, it fails to keep up. The stroke does not lag as if on a
slow system, but if I end a stroke and quicky make another stroke, the
second stroke does not appear.

I notice that the CPU goes up to 100% whenever I paint with the
paint/ink tool, and there's a slight cursor-lag at the end of each
stroke, which I guess is why the system is not catching the next one.

I'm sure this is not due to GIMP's inefficiency, as it works fine on
my friend's much slower computer."

Revision history for this message
sam tygier (samtygier) wrote :

there is a similar bug upstream, but it is for windows

Revision history for this message
Kristoffer Lundén (kristoffer-lunden) wrote :

I'm not sure it's all that similar: if I'm drawing my signature, like the example says, some lines will be missing, but they are drawn mostly in realtime. It's like some strokes never have the time to get registered, or something - but they do in other programs.

Revision history for this message
Daniel Holbach (dholbach) wrote :

Do you still have the problem? Maybe in Edgy or Feisty?

Changed in gimp:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Kristoffer Lundén (kristoffer-lunden) wrote :

It seems to work fine now in 6.10. You can close this bug, thanks!

Revision history for this message
Sebastien Bacher (seb128) wrote :

thank you for the update, marking fixed then

Changed in gimp:
status: Needs Info → Fix Released
Revision history for this message
GFD (gfd-deactivatedaccount) wrote :

I'm running on Feisty and It seems that It was not really fixed. I got an Wacom Graphire 4 and I have the same issue with gimp (cpu at 100% of usage when I use my graphic tablet).

Revision history for this message
Antario (antario91) wrote :

I also have this problem on Hardy with an Aiptek Slim Tablet 600U. It is really anoying... Any fix out there? I'm the only one who can't find anything?

Revision history for this message
Antario (antario91) wrote :

Ok, i was wrong..., it works, but i realised that it doesen't work with compiz enabled. Maybe just for me...

Revision history for this message
Taylor "Ripps" LeMasurier-Wren (ripps818) wrote :

I'm experiencing serious lag in Gimp on Intrepid (Compiz Enabled) with my Graphire 3.
I wonder if this has something to do with the fact that HAL is now in charge of managing input devices.

Revision history for this message
Šarūnas Valaškevičius (rakatan) wrote :

yikes, digging up the same problem in ubuntu 10.10, while using KDE, (did not try to disable graphic effects yet)
the problem is not for signature drawing, it fits in buffer.

as I *guess*, gimp registers input events in a gueue and draws them later, the problem is for slower brushes or when drawing fast (or especially the combination :D) - after buffer is filled up, gimp stops listening for new events. Not sure if this is really the internal workings of gimp, but it describes the problem best.

Revision history for this message
Šarūnas Valaškevičius (rakatan) wrote :

as I could not reopen this bug (the dropdown allows only one choice "fix released" - why??? i.e. I can trash opening new bugs but I cannot reopen one even if it fits perfectly?? ) , I opened

Revision history for this message
Peter Clifton (pcjc2) wrote :

This bug is still present in Natty with a SVN build of gimp.

Revision history for this message
Monstara (monstara) wrote :

I confirm this in Natty with GIMP from the repo.

Revision history for this message
Turi Scandurra (salvatore-scandurra) wrote :

I solved this problem on Natty and a Fujitsu T5010 with this command:

xsetwacom set "Serial Wacom Tablet stylus" TabletPCButton on

Revision history for this message
slug45 (slug45) wrote :

Running 'xsetwacom set "Wacom Intuos3 6x8 stylus" TabletPCButton on' worked on my Intuos3 on 11.04 but disabled both stylus' side buttons.
In order to get them working again I only had to run xsetwacom set 'Wacom Intuos3 6x8 stylus" TabletPCButton off' and both problems were solved.

Revision history for this message
slug45 (slug45) wrote :

^ That worked ok until I turned off the computer and turned it on again the next day. After some searches I found this thread :

I tried running a non-compiz session and gimp was running ok again. It seems it might be a compiz bug.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers