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 322778 - Wacom Tablet rate too low
Wacom Tablet rate too low
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.8.x
Other Windows
: Normal minor
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-11-29 21:26 UTC by Hellday
Modified: 2009-06-23 10:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Airbrush stutter per Wacom (16.64 KB, image/png)
2006-01-23 13:08 UTC, thorwil
Details

Description Hellday 2005-11-29 21:26:46 UTC
When changing the focus to The GIMP the cursor update rate decreases considerably.
Painted strokes end up nooky. I get smoother lines even with my mouse.
GIMP seems to just drop some Data for whatever reason.

The rate drops even more when I set the Wacom Driver mode from "Datenerkennung"
(slow but perfect) recognition to "Standard" or "Einzelmodus".

Other information:
Running on

Win XP SP2  
Wacom Artpad II  Driver v. 4.78-6
AMD Thunderbird 1333, 512MB
Comment 1 Robert Ögren 2005-12-01 20:18:56 UTC
The tablet handling code is in the GTK+ library, and GTK+ on Windows currently
requests a packet rate of 50/second even though the tablet can usually supply
events faster. I guess the original reason for limiting the packet rate is that
a slower computer can't process the events fast enough, but a modern computer is
probably able to handle a faster rate.

When you draw with the tablet in GIMP, how high is the CPU utilization? If it is
already close to 100%, increasing the packet rate could mean that drawing no
longer keeps up with the pointer but starts lagging behind, especially when
drawing with large brushes. 

Some kind of setting would be needed to satisfy both users of fast and slow
computers. See bug #154657 for another tablet issue that needs a setting. As
noted there, "the hard part with changing the [input device] configuration
dialog is that the dialog is provided by GTK+ (GtkInputDialog) but it is GIMP
that saves and restores the settings between sessions, so it involves an API
change to get this to work which is not so fun."

See bug #143460 for another issue that is related to the packet rate. (This is
not a duplicate of that)
Comment 2 Hellday 2005-12-06 19:07:32 UTC
Processing only half the Data doesn't help alot.
CPU load depends mainly on the number of brush es drawn.

The number of brushes per stroke of unit length however does not depend on the
precision to wich the stroke is captured but mainly on its length.

When using the Tablet  Gimp processes all the points it gets from GTK (I suppose). 
Lagging occurs only when drawing too quickly.

With the mouse:
 I get no lagging at all because in case of preformance problems some mouse Data
is simply discarded! this causes jaggyness with fast strokes but eliminates
lagging. It also seems to cause extended jaggyness with repeated short strokes.

I think it would be nice to give Gimp all the tabletdata and let the user decide
wether to process all of it or discard some (mouselike).
Comment 3 Robert Ögren 2005-12-08 21:12:01 UTC
Yes. If the absolute button reporting patch for GTK+ in bug #143460 would be
applied, GTK+ should handle dropped packets much nicer and we could make the
packet queue size a user configurable parameter also.

The main problem here is how to implement the saving of these preferences in a
good way (see comment #1). One conceivable alternative might be to create a new
Wintab configuration dialog in GTK+, add a button to open it from the existing
GTK+ input device dialog, and make it save its setting in a new file like
wintabrc. With that solution there would be no need for API changes, all stuff
would be in GTK+. Is there is a GTK+ or GIMP maintainer that has any suggestions
for how to implement this in a better way?

There is also the tiny detail that someone has to actually write the code. I'm a
bit short on time right now. Is there anyone else that wants to give it a try?
Comment 4 Sven Neumann 2005-12-13 17:54:43 UTC
Reassigning to GTK+ because it seems that this can and should be entirely
handled there.
Comment 5 thorwil 2006-01-23 13:08:11 UTC
Created attachment 57932 [details]
Airbrush stutter per Wacom

I asume this is about the behaviour shown on my image? It was created on Linux, though. The same with mouse results in even colour/alpha. CPU load goes from around 2 - 5 % up to 52% with Wacom, but only if I keep drawing a while. Up to 65% with mouse!
Comment 6 thorwil 2006-01-23 17:05:12 UTC
Just figured out it was a > 1.0 spacing for the brush. Don't remember ever touching this parameter before. I'm sorry.
Comment 7 Hellday 2006-05-12 19:55:43 UTC
To clarify the issue.

For me this problem only occurs in Windows. 
Under Linux the Gimp works equally nicely with mouse or wacom.

Windows:
 some Win App has focus:
  Move the Cursor with your mouse. -> smooth motion
  Move the Cursor with your wacom. -> smooth motion
 any Gimp window has focus:
  Move the Cursor with your mouse. -> smooth motion
  Move the Cursor with your wacom. -> less updates

Linux:
  always smooth

In http://bugzilla.gnome.org/show_bug.cgi?id=143460 performance issues are raised. 
<quote>
"However, there is a potential problem - the rate of
motion events are doubled for me, which causes the CPU usage of The GIMP to
roughly double to around 50-75% on an Intel P4 2.4 GHz, depending on which
drawing tool, brush size etc that is used. I don't know what will happen on a
slower machine, but there could be problems."
</quote>

I also can observe that high CPU load on my Athlon 1333 512MB.
But they appear only over the canvas. No other Gimp windows produce that high a load from motion events while hovering.

With the wacom I don't get over 
90% of CPU usage for brushes of radius 1000
80% for radius 500.
50% radius 100
40% for minimum radius

So why the load for not even drawing anything!??

In preferences switch off  "image windows" "show brush outline" and it drops to about 35%.
Try switching on/off the rulers, they seem to have a sickly huge impact here!

Robert,  I also would consider this performanceissue a bug, and suggest to go for the default packetrate.

- apart from the canvas, motion events are no performance problem, so something with the canvas is wrong
- full packet rate resolves missing clicks bug
- smoother curves
- works with the mouse which has a higher rate
- won't be too problematic for slow machines
- this should bring up no performancehits on the drawing routines because they still are governed by brush spacing.


Btw. why are tablet events qeued and mouseevents discarded?

thanks
Holger
Comment 8 Robert Ögren 2006-05-13 13:03:49 UTC
Holger,

if there is a major performance increase when switching off the rulers then I suggest you create a new bug report against GIMP detailing only that problem. Please indicate how much less CPU is used when the rulers are off compared to when on.

Please note that the low-level tablet handling code in GTK+ is completely different for Windows compared to Linux/X11 so it is not surprising that they may behave differently.

> Btw. why are tablet events qeued and mouseevents discarded?

They are reported to the application in completely different ways and the code to handle them are different. With the current tablet code it is also more important to not lose events as clicks could otherwise be missed.

It is certainly possible to improve the current code, as has already been outlined: Fix up and apply the patch in bug #143460, remove the packet rate hardcoding and decrease the queue size, and possibly provide some way for the user to change the rate. But it requires time to implement and more importantly test.

Comment 9 Tor Lillqvist 2008-06-21 11:20:44 UTC
I wonder if the change in bug #496958 helped? Does this problem still occur with GTK+ 2.12.10?
Comment 10 Tor Lillqvist 2009-01-12 13:10:29 UTC
Can anybody confirm if this problem still occurs?
Comment 11 Tobias Mueller 2009-06-23 10:59:35 UTC
Dear reporter, can you please try with a more recent version of GTK+ and reopen if it still exists? Thanks in advance.
I assume this issue is OBSOLETE by now.