GNOME Bugzilla – Bug 573154
Tracker bug to sanitize motion event handling
Last modified: 2018-04-15 00:10:06 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.
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
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
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.
Example: bug 736690
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.
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