All,
I believe #6901 "Can not continually move a floating selection with
a pressure sensitive pointer." is very nearly intractable.
1) The Xlib Programming Manual notes that for the core pointer,
when PointerMotionHintMask is set, only one motion event will be
sent per change of position of the mouse (Appendix E, "Event
Structure Members" discussion of "is_hint" flag). The corresponding
guarantee is not made for XInput events. This weekend (11/24 -11/26/2000)
I used xscope to monitor the client/server traffic at the X protocol level.
For Wacom tablets using the Wacom 4.5.0 driver, hinted motion reporting
is confined to one motion event per change in some button state, giving
rise to the behavior reported in #6901. There is no indication that this
is anything other than Wacom driver specific behavior; other drivers may
cut more closely to core pointer behavior, but since the XInput Extension
document furnishes very little guidance about what driver writers should do
with the hint, a wide spectrum of hint behavior is possible.
(being a "hint" there is no obligation for driver writers to
honor it, and hinters should not make too many assumptions about particular
behavior resulting from the request).
Without uniform behavior, there is very little in the way of a common
approach that Gimp or GTK can take after requesting hinted motion from
a device. Large gobs of "if (this) {...} else if (that)..." dance before
me eyes.
2) The only tractable approach that occurred to me was to abandon the hint
request approach (i.e., remove GDK_POINTER_MOTION_HINT_MASK in any event mask
flag of gdk_pointer_grab() where edit_selection tool methods may follow).
This avoids variable behavior surrounding motion hinting with external devices.
While Adam Moss had furnished an event queue trimmer to telescope the resultant
flood of motion events, the underlying gdk code does not just manage a
client side "GDK event queue" but issues XPending() to flush possible events from
the server; much I/O waiting occurs on the gdk_event_get() call because
of this. (see gtkutil_compress_motion() cursorutil.c Line 509). I found
the results fairly sluggish (but not as sluggish as shunting
gtkutil_compress_motion() and mindlessly processing every motion event).
3) An approach that I did not try runs along the line of
changing the compression strategy of gtkutil_compress_motion() so that it
rejects any motion event where a x*x + y*y - (x +dx)*(x +dx )- (y +dy)*(y +dy)
delta is less than a pre-set difference. Such a filter is applied to all
motion events. This may be a bit radical this close to the Fabled 1.2 Release.
Observations? Suggestions? (Adam?)
Be good, be well
Garry
PS #6901, by the way, bears no particular relationship to #10498, apart from
the happenstance of being tablet-based. That bug stems from GTK+
bug #32617, which inserts an unrequested button-press event flag
in gdk_pointer_grab() for XInput devices only.
