Event redirection adventures

[Keith Whitwell]

Keith Packard wrote:
> Ok, I've spent about two weeks thinking about event redirection and
> haven't come up with an obvious simple plan. Either I'm dense, or this
> is a whole lot harder than I want it to be.
> 
> We're talking here about the mapping inside the server between various
> coordinate spaces for the purpose of processing and delivering mouse
> events. This is currently done by assuming a simple translation
> transformation between screen and window coordinate spaces.
> 
> With Composite'd environments starting to explore projectively
> transformed 2D applications,  our trivial transforms aren't going to
> hack it any longer. We clearly need to place the transformations under
> application control and permit some pretty wild stuff at the same time.
> 
> There are two basic computations needed in this environment. The first
> is to transform an arbitrary screen position to a position relative to a
> specific window (coord transformation). The second is to detect which
> window is directly under a specific screen position (hit detection).
> 
> 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.
> 
> Consider a simple case -- Pointer in Window A and Pointer grabbed by
> Window B. In this case, events must be delivered wrt Window B, which
> means that the server must have coord transformation data that computes
> positions relative to Window B, even though the cursor is not inside it.
> 
> 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.
> 
> 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. Coordinate transformation must occur in FixupEventForWindow,
> which occurs right as events are being send to the client.
> 
> 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.
> 
> For transforming coordinates while the pointer is grabbed, we need the
> input redirect client to be told which window to return information for.
> 
> 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.
> 
> Cosider a simple 32-bit pixmap 'painted' with Window IDs. This could be
> used for efficient hit detection and would make XYToWindow at least as
> fast as it is today.

I was skimming til I hit this - seems fairly extreme - consider a 2k x 2k 
desktop - no longer the sole preserve of air traffic controllers - you've just 
added a 16meg data structure...  If you really need to do this sort of lookup, 
consider something like a BSP tree which could generalize the current 
axis-aligned window boundary structure to cope with arbitary polygonal shapes...

Keiht