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 167960 - WACOM Graphire3 Tablet cursor function (automatic scroll in GIMP doesn't work properly with tablet)
WACOM Graphire3 Tablet cursor function (automatic scroll in GIMP doesn't wor...
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
2.2.x
Other Windows
: Normal major
: 2.2
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-02-20 17:15 UTC by David E. Myhr
Modified: 2008-01-15 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Suggested patch (1.46 KB, patch)
2005-02-23 21:27 UTC, Robert Ögren
none Details | Review

Description David E. Myhr 2005-02-20 17:15:20 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.
Comment 1 Sven Neumann 2005-02-20 17:19:59 UTC
Does this happen with the tablet only or with the mouse as well?
Comment 2 David E. Myhr 2005-02-20 17:27:37 UTC
It seems to be the WACOM tablet using their mouse or pen, if I use a different
mouse it functions as expected.
Comment 3 Sven Neumann 2005-02-20 18:22:32 UTC
That would also be a problem in the GTK+ library then. Should perhaps be merged
with bug #167958.
Comment 4 Sven Neumann 2005-02-21 11:50:19 UTC

*** This bug has been marked as a duplicate of 167958 ***
Comment 5 Robert Ögren 2005-02-21 17:40:55 UTC
This is not the same as bug #167958, reopening and reassigning to GTK+.
Comment 6 Robert Ögren 2005-02-21 22:44:22 UTC
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?
Comment 7 Sven Neumann 2005-02-22 20:18:16 UTC
I wouldn't object against this change as long as a short comment is being added,
perhaps refering to this bug report.
Comment 8 Robert Ögren 2005-02-23 21:25:53 UTC
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. 
Comment 9 Robert Ögren 2005-02-23 21:27:40 UTC
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.
Comment 10 David E. Myhr 2005-03-05 18:17:40 UTC
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.
Comment 11 Robert Ögren 2005-03-05 18:41:50 UTC
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.
Comment 12 weskaggs 2005-03-06 16:58:27 UTC
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.
	
Comment 13 Robert Ögren 2005-03-06 17:21:53 UTC
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.
Comment 14 Sven Neumann 2005-03-06 18:31:16 UTC
If possible, the small change suggested by Robert should still be backported to
gimp 2.2.
Comment 15 weskaggs 2005-03-06 20:51:53 UTC
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.