My thoughts on InputOnly window proxies for 3D objects

[Deron Johnson]

More on 3D proxy windows.

In this mail I agree with Keith that the selection of cursor
visual representation can be moved upstream into the DS
Event Deliverer, effectively solving the 3D grab cursor
display problem.

I also mention that it is important that the 3D proxy window
information in the X server be kept up to date with what
is visible in the 3D scene graph. This must be done synchronously
with the event stream. Although it's a significant change to
LG, I believe this can be done. At any rate, it's worth prototyping.

Deron Johnson wrote On 01/05/06 11:41,:
> 
> Keith Packard wrote On 01/04/06 11:59,:
> 
> 
>>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.
> 
> 
> Okay. I'll keep the cursor movement in the Picker but I'll try to move
> the selection of the cursor visual representation up into the
> EventDeliverer.
> 
> 
>>>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? 
> 
> 
> I am concerned that unless I can keep the proxy windows up to date with
> the scene graph in a way which is synchronous to the event stream that
> I might end up with a situation where a grab could occur on an object
> which is not actually visible. I've talked with our scene graph expert
> about this. Fortunately, the Picker is synchronous to Java3D's frame
> rendering--it is called once per rendering frame. There is a way that
> we can make all structural changes to the scene graph occur frame
> synchronously. That means that each time the Picker runs it always
> will have up-to-date information about the scene graph and it can
> send down any changes to the proxy windows and focus/sprite traces
> it sends down any events. So it's a bit involved on the Display Server
> side, but I believe it can be made to work.
> 
> 
> 
>>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.
> 
> 
> Actually, what I am trying to achieve is for the grab semantics of LG
> to be exactly the same as that of X.
> 
> 
>>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.
> 
> 
> I'm not sure I understand this comment. X was never just another LG
> application. In the LG environment, the X server has been in charge all
> along.
> 
> I will continue to research the idea of proxy windows and try to
> prototype it. But at this point I'm not sure when I'll get to it.
> In my mind, the topmost window feature is more urgent.
> 
>