[compiz] Re: [PATCH] Transparent cube

[David Reveman]

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