Event redirection adventures

[Deron Johnson]

Keith Packard wrote On 01/09/06 02:03,:

> The problem is that coordinate transformation and hit detection are
> currently synchronous wrt event processing, which means that decoupling
> these and letting an external client help figure out the right answers
> turns out to be really hard.

I would hesitate to say that it is "really hard." Somewhat challenging,
yes, but solvable.

> Now, consider a harder case -- the Pointer is frozen and events are
> backing up. The window manager reconfigures windows and calls
> AllowEvents. Events must now be *reinterpreted* wrt the new window
> configuration for appropriate delivery.

Good point.  My current prototype doesn't handle this case. The problem
is that ComputeFreezes doesn't funnel the replayed events through
CoreProcessPointerEvent and CoreProcessKeyboardEvent, which is where
I do my redirection.

> This latter case means that our plan for placing event redirection right
> at the raw event delivery mechanism *will not work*. Instead, for this
> to work, it must happen far later in the event processing pipeline. Hit
> detection must occur in XYToWindow, which happens even with replayed
> events. 

We also need to make sure that XYToWindow is called for button events
too. It is called for button events from ComputeFreezes, but not from
CoreProcessPointerEvent. This is easy enough to fix.

> Coordinate transformation must occur in FixupEventForWindow,
> which occurs right as events are being send to the client.

Agreed.

> To make XYToWindow able to redirect pointer positions to clients, we
> must make it possible for it to pend the processing of an event and
> stick it somewhere until an answer is received from the client.

Or just route the entire event stream through the redirection client.
That is what I do. It's a whole lot simpler and doesn't have any
detectable negative impact on performance.

> One thing I'd like to see discussed here is whether it makes any sense
> to try and stuff suitable transformation data inside the X server.

Are you talking about transformation data or hit detection data?

> Does it make sense to explore this server-resident redirection solution?
> Or should we only consider solutions which involve pumping events
> through an external client?

The hit detection information that Java3D uses is called a "binary hull
tree." It is a binary tree of enclosing bounds objects. The bounds can
be trivial (i.e. cubes) or can be complex polytopes.

In general, the bounds information can be arbitrarily complex and the
data structure can be quite large. Not only would the data structure
need to be duplicated in two places (in the redirection client and the
X server) but the copy in the X server would need to be kept up to date
in a way which is synchronous with the event stream. (Note that
the X window tree is update synchronously to the event stream).

Furthermore, it is very possible that portions of this duplicated data
will never be used because the user will never move the mouse over
certain objects.

I've considered this type of design in the past and I decided that it
was much easier to send small packets of relatively infrequent data
(user events) from the X server to the redirection client and back,
than it would be to send potentially huge amounts of potentially
rapidly changing (e.g. 30 fps) hit detection information from the
redirection client to the X server. The bandwidth required for
the former case is orders of magnitude less.