[compiz] Re: [PATCH] Transparent cube

[Dennis Kasprzyk]

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.

Dennis