GNOME Bugzilla – Bug 322778
Wacom Tablet rate too low
Last modified: 2009-06-23 10:59:35 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
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)
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).
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?
Reassigning to GTK+ because it seems that this can and should be entirely handled there.
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!
Just figured out it was a > 1.0 spacing for the brush. Don't remember ever touching this parameter before. I'm sorry.
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
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.
I wonder if the change in bug #496958 helped? Does this problem still occur with GTK+ 2.12.10?
Can anybody confirm if this problem still occurs?
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.