GNOME Bugzilla – Bug 167960
WACOM Graphire3 Tablet cursor function (automatic scroll in GIMP doesn't work properly with tablet)
Last modified: 2008-01-15 12:48:23 UTC
Distribution/Version: XP Home SP1 and SP2 I am using the program to make measurements on scanned pictures. I zoom out, pick a starting point and then move to the ending point. If the end point is out of view and I move the cursor past the edge the image it pans as expected but it will not stop once until it reaches the edge of the window. The end point cannot be selected if it is not in the image after stopping.
Does this happen with the tablet only or with the mouse as well?
It seems to be the WACOM tablet using their mouse or pen, if I use a different mouse it functions as expected.
That would also be a problem in the GTK+ library then. Should perhaps be merged with bug #167958.
*** This bug has been marked as a duplicate of 167958 ***
This is not the same as bug #167958, reopening and reassigning to GTK+.
The reason this problem occurs is that gdk_device_get_state in the GDK win32 backend just returns the coordinates from the last event for tablet devices, since there is no easy way to get the current device coordinates through the Wintab API. Normally this works fine, but it interacts badly with the autoscroll code in gimp_display_shell_canvas_tool_events (app/display/gimpdisplayshell-callbacks.c, gimp-2-2 from anoncvs): 1062 gimp_display_shell_get_device_coords (shell, 1063 mevent->de 1063 vice, 1064 &device_co 1064 ords); 1065 1066 if (device_coords.x == mevent->x && 1067 device_coords.y == mevent->y) 1068 { 1069 /* Put this event back on the queue 1070 * so it keeps scrolling 1071 */ 1072 gdk_event_put ((GdkEvent *) mevent); 1073 } Due to the above mentioned implementation of gdk_device_get_state, the coordinates returned by gimp_display_shell_get_device_coords will be the same as for the last motion event received and the event is requeued. Since there is an event in the queue, _gdk_events_queue won't process any new windows messages including tablet messages which would otherwise update the coordinates for the tablet devices, so the next time the same event is processed, the coordinates will stay the same and the autoscroll continues until the border of the image is reached. I think it would actually be much easier to fix this problem in GIMP rather than GTK+. The simplest solution is probably to just avoid putting the event back in the event queue if the event is not from the core pointer device and we are running on the win32 platform. The tablet produces motion events even when the stylus/puck is held absolutely still so this keeps the autoscroll going anyway. I did a quick test and just commented out the gdk_event_put line, and that made the autoscroll work nice with my tablet. To make it work for a regular mouse as well, we would have to check if the device is the core pointer, and check for win32. Perhaps like this: if (device_coords.x == mevent->x && - device_coords.y == mevent->y) + device_coords.y == mevent->y +#ifdef G_OS_WIN32 + && mevent->device == gdk_display_get_core_pointer ( + gdk_display_get_default ()) +#endif /* G_OS_WIN32 */ + ) { /* Put this event back on the queue * so it keeps scrolling GIMP developers: What do you think of this?
I wouldn't object against this change as long as a short comment is being added, perhaps refering to this bug report.
With the GIMP HEAD branch, this is no longer a problem as the autoscroll functionality seems to be rewritten in a much nicer way. I just pulled and compiled HEAD and autoscroll works nice with my tablet. I'm sorry that I didn't test that earlier, I haven't had time to look at HEAD until now. Still, it might be nice to add the workaround to the stable branch, so I'll assign this back to GIMP and attach a patch with the suggested change and including the requested comment.
Created attachment 37858 [details] [review] Suggested patch Against latest gimp-2-2 from anoncvs, tested on Windows XP SP2 with a Wacom Graphire 3 tablet.
Gentlemen, I have downloaded and installed GIMP 2.2.4/GTK+ 2.6.2 and continue to have the same problems. To reiterate, scrolling continues until it reaches the edge of the window and cannot be stopped before. With the table puck or pen set to mouse mode the cursor does not track the tool position. It appears to be scaled somehow, the arrow moves faster than the tool position. I don't know if 2.2.4 is the version mention in comment #9, if not, how will I know when the fixed version is available. Thanks for your help.
That's because those problems have not been fixed in those versions, sorry. Comment #9 is a suggested change for the GIMP source code that should fix the scrolling problem, but the fix has not been incorporated in the GIMP source code yet. When/if the change is incorporated, a comment will be added here by the person who does it, and then you would have to wait until a new version of GIMP is released. The mouse mode problem is bug #154657, and there is no estimate on when that bug will be fixed. If it is fixed, a comment will be added there. Until then, use pen mode.
I have committed the patch, but the bug reporter should note that it probably will not be enough to make him happy. The rewrite of autoscrolling in HEAD was done to fix the problem described in bug #8269: autoscrolling was so fast that hitting the edge of the window usually caused immediate autoscrolling to the edge of the image, without needing any error in processing of pointer events. The changes were sufficiently complex that there is no chance of them being backported to 2.2. So the bottom line is, this problem will not really be fixed until GIMP 2.4 comes out. 2005-03-06 Bill Skaggs <weskaggs@primate.ucdavis.edu> * app/display/gimpdisplayshell-callbacks.c: applied patch from Robert Ögren to improve autoscrolling with tablets in Windows, see bug #167960.
Well, at least on my machine, autoscrolling with the tablet works rather well (better than with the mouse) with that patch and the probable reason is that it doesn't scroll as fast as the machine can repaint the canvas but only as fast as the tablet provides events (50 times per second). It is still a bit fast and you have to be careful not to move the stylus too far away from the edge of the window, so the improvement in bug #8269 will certainly be appreciated, but I definitely think it is better than how it was before. Thank you for committing the patch.
If possible, the small change suggested by Robert should still be backported to gimp 2.2.
Sorry, I was unclear -- comment #12 meant to say that the change was committed to the gimp 2.2 branch. It is not needed in HEAD. I suppose this can be declared FIXED now, although the fix falls somwhat short of perfection. For perfection, we will have to wait until Gimp 2.4.