[compiz] [PATCH] Transparent cube

[David Reveman]

On Mon, 2007-05-07 at 21:24 +0300, Roi Cohen wrote:
> Hi.
> 
> I re-created my patches to work on latest git, and use the order system.
> David, what do you think of these patches now?

Did we solve all issues with the order interface? How can multiple
plugins use that interface reliably? I'd like to make sure that we at
least have a good plan for how to deal with that before we add this.

- David

> 
> Regards,
> Roi.
> 
> On 5/4/07, David Reveman <davidr at novell.com> wrote:
> > On Tue, 2007-05-01 at 23:06 +0200, Dennis Kasprzyk wrote:
> > > Am Dienstag, 1. Mai 2007 22:54 schrieben Sie:
> > > > On Tue, 2007-05-01 at 23:29 +0300, Roi Cohen wrote:
> > > > > Hi David.
> > > > >
> > > > > I thought about your suggestion a bit more, and i think it has a
> > > > > problem, although it's a bit hard to explain it.
> > > > > How will plugins exactly wrap this function? I mean, obviously they
> > > > > will just call the WRAP / UNWRAP macros, but what i'm asking is, what
> > > > > will they actually do inside this function?
> > > > > I guess it needs to be something like this:
> > > > >
> > > > > nextInStack(w)
> > > > > {
> > > > >   if (Plugin makes an effect and needs to change order)
> > > > >           return next;
> > > > >
> > > > >   UNWRAP;
> > > > >   call;
> > > > >   WRAP;
> > > > > }
> > > > >
> > > > > If one plugin needs to change painting order, plugins loaded before it
> > > > > won't get the chance to change their painting order.
> > > > >
> > > > > 3D and cube will still work together, but only because of "luck" - 3d
> > > > > needs to be loaded before cube (it needs the openGL matrices of the
> > > > > cube's transformations to know how to reorder the painting) which
> > > > > means that theoretically, 3d's paint order won't be executed. However,
> > > > > it will work because 3d doesn't need to change painting order for ftb
> > > > > faces, and cube doesn't need to change painting order for btf faces.
> > > > > Again, I consider this as a "lucky coincidence", both 3d and cube will
> > > > > work, but it shows why I think wrapping this function is somewhat
> > > > > problematic.
> > > > >
> > > > > Dennis Kasprzyk suggested another approach to this problem - instead
> > > > > of wrapping this function, we will pass another argument to
> > > > > paintTransformedScreen which is:
> > > > > struct CompWindowListSort {
> > > > >   // Function pointers
> > > > >   FirstInStackProc* first;
> > > > >   LastInStackProc* last;
> > > > >
> > > > >   NextInStackProc* next;
> > > > >   PrevInStackProc* prev;
> > > > > }
> > > > > This way, plugins won't wrap this function, and the plugin which is
> > > > > loaded first gets the call on painting order, instead of the last
> > > > > plugin which is loaded last.
> > > > > It fixes the problem with 3d and transcube - 3d's paint order will
> > > > > always be prefered over cube's one.
> > > > > I'm not really sure this is the best solution - there isn't really a
> > > > > reason to prefer the first loaded plugin over the last loaded one.
> > > > >
> > > > > Do you think we should stay with your original idea, ignoring the
> > > > > problems that will occur when 2 different plugins want to change
> > > > > painting order (after all, similar problems occur with window
> > > > > transformations etc), or do you have another idea?
> > > >
> > > > Yes, maybe it's better to just require a depth buffer and destination
> > > > alpha for these kind of effects and construct an proper interface for
> > > > that instead.
> > > >
> > > > - David
> > >
> > > But this could also cause problems with something like skydome. I think that
> > > every solution can cause problems with other plugins, but I think it is
> > > better to add a solution that will not add additional dependencies. And I
> > > think that the order change system is more flexible so that we could use it
> > > for another effects later.
> >
> > I fail to see how it could cause problems with the skydome but using
> > destination alpha is definitely not going to work with the blur plugin.
> > We're going to have to address the problem with drawing intersecting
> > translucent objects at some point but as we don't have a perfect
> > solution for that yet, the order system seem like a good idea to start
> > with.
> >
> > - David
> >
> > _______________________________________________
> > compiz mailing list
> > compiz at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/compiz
> >