motion hint processing API seems to be broken

[Stanislav Brabec <sbrabec suse cz>]

Hallo.

After experimenting, reading GTK+ source code and documentation, the X
protocol and server specification, I think, that the current design of
motion feedback using motion hints is broken, and its X11 back-end is
broken for sure.

All GTK+ callback implementations you can find are broken and don't do
what people expect. I prepared a small utility that demonstrates this
problem by spending 100 milliseconds in each motion callback:

http://bugzilla.gnome.org/show_bug.cgi?id=587714#c2

It seems that gdk_event_request_motions() effectively sends events
to /dev/null instead of processing them and deprecated use of
gdk_window_get_pointer() does not work with more input devices (and
cause early release of next motion hint).

I am not sure, what will be the optimal fix, but it seems that the
current API and recommendation cannot work. I would like to see a
function, that cleanly updates coordinates (and causes issuing of a new
motion hint) and an internal semaphore that blocks motion hint callbacks
until complete finishing of the previous event (including re-rendering
in the main loop). Regarding internal GTK+ code, it must never eat
motion hints, as it happens now (caused by calls of XQueryPointer and
XGetMotionEvents without generating an event).


Existing implementations:


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:


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/