Hallo. After a long experimenting, reading GTK+ source code and documentation, digging in the X protocol and server specification, I started to think, that the current design of motion feedback using motion hints is broken, or at least its X11 back-end is broken. All callback implementations you can find are broken. I prepared a small utility that demonstrates this problem: http://bugzilla.gnome.org/show_bug.cgi?id=587714#c2 It seems that gdk_event_request_motions does not do what one would. Instead of processing the latest events, it effectively sends all newer events to /dev/null. I am not sure, what would be the optimal fix. It is possible, that the fix may affect the API or recommended implementation of the motion feedback (see the discussion in the bug above and description below). 1. handle (motion_event->x,motion_event->y) motion gdk_event_request_motions (motion_event); This is recommended in documentation, but when motion stops, it loses events (gdk_event_request_motions sends events to /dev/null) and pointer remains outdated: 2. gdk_window_get_pointer (..., &x, &y); handle (x,y) motion This works nice with core events and does not work with non-core events: 3. gdk_event_request_motions (motion_event); handle (motion_event->x,motion_event->y) motion This is not recommended anywhere, but often used in GTK+ code. It loses events (gdk_event_request_motions sends events to /dev/null) and pointer remains outdated: -. Also following code has no effect, at least with X11 backend and modern X11 servers. If you use motion hints, all X11 events have is_hint set, the else is never executed. if (motion_event->is_hint) do something else do something else Processing motion event hint with coordinates stored in the event may not be an optimal solution. With a high CPU load, these coordinates may be outdated and using current coordinates may improve visual look of the feedback. (According to X11 documentation, getting cursor position also orders delivery of a new motion hint.) On the other hand, it is possible that mouse button was released in time between and rendering motion feedback has using actual position may cause jitter at the end of the motion. Maybe how gdk_event_request_motions() should generate motion event under some circumstances, and feedback implementation should ignore motion hints. Note that this bug is a part of larger set of motion feedback bugs: http://bugzilla.gnome.org/show_bug.cgi?id=573154 Here is another tool for searching of incorrect GTK+ feedback: http://pack.suse.cz/sbrabec/gtk-dilatory/ -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@xxxxxxx Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
