input transformations

[Kristian Høgsberg]

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