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 573154 - (motion-event-tracker) Tracker bug to sanitize motion event handling
(motion-event-tracker)
Tracker bug to sanitize motion event handling
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.15.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on: 307559 495320 529908 573160 573163 573164 573166 587714 623865 641514 736690
Blocks:
 
 
Reported: 2009-02-25 17:37 UTC by Federico Mena Quintero
Modified: 2018-04-15 00:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Federico Mena Quintero 2009-02-25 17:37:32 UTC
We have bugs with a few patterns:

1. Code requests POINTER_MOTION_HINT_MASK and then it does this in the motion_event handler:

   if (event->is_hint) {
       gdk_window_get_pointer (..., &x, &y);
       xpos = x;
       ypos = y;
   } else {
       xpos = event->x;
       ypos = event->y;
   }

This is wrong; code that requests motion hints should use gdk_event_request_motions().

2. Code doesn't request HINT_MASK at all, and it ignores a motion event's coordinates.  Instead, it uses gdk_window_get_pointer() all the time.  This gives you out-of-sync positions if the mouse has moved between the time the event was generated, and the time that function is called.

3. Code that implements press-drag-release doesn't update its state with the coordinates from the ButtonRelease event.  Instead, it assumes that the last motion event had the final coordinates.
Comment 1 Stanislav Brabec 2009-07-08 11:39:55 UTC
I found, that recommendation  for 1. (that can be found in the documentation) does not work well. Use of gdk_event_request_motions() gives worse results than gdk_window_get_pointer() (which does not work for non-core pointer).

Reported as bug 587714. Motion feedback test tool is attached there.


I created a small tool for testing motion feedback bugs: GTK-Dilatory tool runs applications slowly with big retardation in the main loop:

http://pack.suse.cz/sbrabec/gtk-dilatory
Comment 2 Stanislav Brabec 2010-07-08 21:35:08 UTC
I found another pattern:

4. Code that implements press-drag-release and allows time disparity by combining of GDK_CURRENT_TIME for one event type and stored event time for release.

Example: bug 623865
Comment 3 Stanislav Brabec 2014-09-15 20:46:58 UTC
And another bug pattern found:

5. Code that uses grab to implement motion event handler, and intends to be left after a button release. But the grab itself can be called after button release.
Comment 4 Stanislav Brabec 2014-09-15 20:48:27 UTC
Example: bug 736690
Comment 5 Matthias Clasen 2018-02-10 04:59:24 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 6 Matthias Clasen 2018-04-15 00:10:06 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new