motion hint processing API seems to be broken

[Stanislav Brabec <sbrabec suse cz>]

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 suse cz
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/