[compiz] Re: input transformations

[David Reveman]

On Mon, 2007-02-05 at 15:22 -0800, Deron Johnson wrote:
> Xavier Bestel wrote:
> 
> >Le lundi 05 février 2007 à 16:10 -0500, David Reveman a écrit :
> >  
> >
> >>On Mon, 2007-02-05 at 11:11 -0800, Deron Johnson wrote:
> >>    
> >>
> >>>It's hard for me to evaluate this without some higher level context.
> >>>What sort of window transformations are you aiming to support
> >>>3D perspective affine transformations? What sort of 3D objects will the
> >>>windows be mapped onto? There are a variety of possibilities:
> >>>a quad of infinite thinness, a flat slab (rectangular parallelipiped) or
> >>>any arbitrarily shaped 3D object. And, do you want to permit interaction
> >>>with transformed windows or use transformation only for transitional 
> >>>effects?
> >>>      
> >>>
> >>I'd like us to be able to support an arbitrarily shaped 3D object even
> >>though I don't have any good use cases for that yet. The most important
> >>use cases right now are scaling, translating and duplicating windows but
> >>we'll definitely use this for more complex transformations soon.
> >>    
> >>
> >
> >Then take into account "non-contiguous windows" (imagine a compiz/beryl
> >plugin which "explodes" a window into many pieces).
> >
> >	Xav
> >
> >
> >  
> >
> If you want complete generality and full access to 3D effects then I 
> would recommend
> that you route the X events through an external picker which has the 
> scene graph
> in its address space (like LG does). 

>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?

> But if you really want to have the 
> scene graph inside
> the X server I would recommend keeping it very simple and to just 
> provide a single
> contiguous tri-mesh for a window. This would cover 99% of the forseeable 
> use cases
> and you could always extend it later on.

Non-contiguous windows are important so I wouldn't want an
implementation that didn't support that. It didn't add any complexity to
support it in my implementation but I can't be 100% sure of that yet as
it's not fully complete though.

The only problem I see with a tri-mesh approach is that you'll have to
increase the resolution of the mesh to have it match the output in some
cases.

- David