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


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.

Reply via email to