input transformations

[Deron.Johnson at Sun.COM]

The use cases for an external picker are 3D environments such as
Looking Glass and Croquet. These projects are characterized by having
very large scene graphs, use of very sophisticated graphics features,
the need for high bandwidth access to update the scene graph and many
interactive visual objects that the X server doesn't manage as
windows.

When I started on the LG project, the first thing I investigated was
putting Java3D (the scene graph library I was using) inside the X
server. No dice. Java3D is a very multithread rich library and the X
server innards are thread hostile. So I decided to put the 3D graphics
outside the X server and route the events out to it and back into the
X server. This turned out to be a good decision. It allows for choice
in terms of the scene graph library to be used, it allows for faster
implementation of new graphics features, fast access to scene graph
updates (you don't need to go through the X protocol) and is generally
a cleaner and easier solution. And the X server doesn't become bloated
by a new PEX-like thing (for those of us who recall the monstrosity
that was PEX).

What I would like to see is an infrastructure which accomodates both
types of picking--both server internal and server external. Support
for external picking in the X server is very important for LG.

Furthermore, the additional infrastructure that I'm proposing is very
minor--just one extension request to load a picker into the server
(XPickerAcquirePicker) and one to associate it with a window.  This
minor addition would accommodate all points of view.


Kristian Høgsberg wrote On 02/06/07 13:21,:

>On 2/6/07, Deron Johnson <Deron.Johnson at sun.com> wrote:
>  
>
>>David Reveman wrote:
>>
>>    
>>
>>>>From the talks keithp has given on the subject I've understood that
>>>implementing this properly is very hard, if not impossible. Is that not
>>>the case anymore?
>>>      
>>>
>>In December I came up with an idea which I discussed with Keith which
>>may finally solve the problem of
>>correctly routing events between the X server and an external "picker"
>>client which owns the scene graph. At that time
>>he was advocating for the idea of a simple in-server picker. (By
>>"picking" I mean using 3D geometry to map transform
>>the event). So together we came up with an idea which I call "plug-in
>>pickers."
>>    
>>
>
>Hi Deron,
>
>I understand that the pluggable picker is a very flexible approach,
>but what does it actually acheive that you can't do with a tri-mesh?
>What kind of geomerty or picking methods do you have in mind that can
>not be describe as a mesh of triangles?  There has to be a number of
>really good use cases that can't be expressed as a tri-mesh to warrant
>this level of complexity.
>
>The only idea that I can think of is that a pluggable picker can
>convert the coordinates corresponding to an exact model of the scene
>graph.  For example if a window is wrapped around a perfect sphere,
>the corresponding picker can use the exact formula for mapping the
>screen coordinates into window coordinates.  But the key here is that
>since you have to decompose your objects into triangles to render them
>anyway, this extra precision doesn't buy you anything.  Even if the
>input remapping is "better" in some sense, it deviates from the
>on-screen geometry and is effectively less precise.
>
>That's all I can think of, and it doesn't really justify the big
>design you sketched out above.  I'm sure you have a number of more
>realistic use cases since you've been working with this for a while,
>and I'm curious as to what they are.
>
>thanks,
>Kristian
>_______________________________________________
>xorg mailing list
>xorg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xorg
>  
>