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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz