My thoughts on InputOnly window proxies for 3D objects

[Deron Johnson]

In addition to discussing topmost windows, Keith and I have
also been discussing changes to the 3D grab portions of my
input document.

One of the weaknesses of my current design is that I cannot
display a grab cursor for 3D grabs. By keeping the cursor
motion tracking in the DS Picker but moving the selection
of the cursor visual representation upstream into the
EventDeliverer this problem can be solved.

In addition, Keith is proposing that instead of doing
a pre-grab test for 3D grabs in the Picker that we shadow
the 3D scene graph grab information in the X server by
creating an X "proxy window" for each 3D object that
has registered grabs. This is an idea we had discussed
before but now we are revisiting it. The advantage is that
it keeps 100% of the grab decision making the the X server.


Keith Packard wrote On 01/04/06 11:59,:
> On Wed, 2006-01-04 at 11:11 -0800, Deron Johnson wrote:
> 
>>Hi Keith,
>>
>>I've been thinking about your suggestion to use InputOnly window
>>proxies for 3D objects. Unfortunately, it doesn't look like it will
>>help that much.
>>
>>First, right now my Picker performs cursor tracking based on on the
>>raw device event stream that comes from the X server.  Grab processing
>>in the X server happens after this. If I move the cursor tracking to
>>be upstream from the grab processing (in what I call the Event
>>Deliverer of my Display Server) I will introduce additional latency in
>>my cursor tracking, which will hurt interactivity. And even if the
>>cursor tracking were to be moved upstream in this way, my current
>>approach to 3D grab handling would provide all the capabilities that
>>the proxy window approach would provide.
> 
> 
> Cursor tracking and cursor selection are different operations; the X
> server performs cursor tracking as close to the hardware as possible,
> either from within the kernel, from a signal handler or a separate
> threads. Updates to the cursor image are separately managed from the
> normal X server flow of control. Having the cursor image lag for a short
> period of time hasn't appeared to cause any particular troubles here;
> the key is to keep *some* cursor image wired as closely to the mouse as
> possible.
> 
> 
>>Secondly, my current 3D library, Java3D, provides a way for me to keep
>>track of what 3D objects are being added to the scene graph, but this
>>method is event based and so I am notified of the changes AFTER they
>>occur on the screen. Therefore, this method is not synchronous with
>>the display and the event stream. One could conceive of modifications
>>to Java3D to force it to contact the X server BEFORE adding a 3D to
>>the scene graph, but this would require a new API, which is relatively
>>difficult to get added to Java3D at this point.
> 
> 
> I don't understand the relevance of this point. Are you concerned that
> an object will be made visible before the associated cursor can be
> drawn? 
> 
> 
> The question is whether X or LG is in control of mouse grabs. Right now,
> it seems that X semantics are far more complex than LG semantics and
> that you cannot reflect the X semantics in the LG world. The converse is
> trivial; LG mouse semantics are easily reflected as a collection of X
> passive and active grabs.
> 
> In my ideal world, some über display system would control the
> distribution of mouse and keyboard events, and would provide some
> mechanism for both LG and X to register appropriate state to model their
> respective mouse grab policies. We don't have that yet, and so it seems
> far more practical at this stage to address the lack of X semantics in
> the LG model by having X placed in charge of the input devices and let
> LG register its interest in events using X semantics. That seems
> workable, and avoids distributing the information about grabs to two
> semi-cooperative agents.
> 
> When X was just another LG application, it made sense to avoid mirroring
> state needlessly like this; now that X is back in charge (at least for
> now), I think it's reasonable to revisit that architecture and approach
> things in a new way.
> 
> -keith
>