[compiz] Re: [PATCH] Transparent cube

Tue May 1 13:29:29 PDT 2007

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?

Roi.

On 5/1/07, David Reveman <davidr at novell.com> wrote:
> On Fri, 2007-04-27 at 03:13 +0200, Dennis Kasprzyk wrote:
> > Am Donnerstag, 26. April 2007 23:08 schrieben Sie:
> > > On Wed, 2007-04-25 at 23:48 +0200, Dennis Kasprzyk wrote:
> > > > Am Mittwoch, 25. April 2007 23:21 schrieb David Reveman:
> > > > > On Sun, 2007-04-22 at 14:22 +0300, Roi Cohen wrote:
> > > > > > Hi,
> > > > > > I re-generated the patches, so it will work now against latest git.
> > > > > > Please note that the vertical rotation bug is now fixed, due to this
> > > > > > commit:
> > > > > > http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=36ca8
> > > > > >bf25 9d79ef5ee3630e1741a213163ebbfb6
> > > > > >
> > > > > > David, what do you think of these patches?
> > > > > > Some feedback is still appreciated.
> > > > >
> > > > > I'm interested in the transparent cube feature but I'm not very happy
> > > > > about the set of patches that is required to get this working in the
> > > > > current drawing framework. I don't want to push that additional
> > > > > complexity into the core and force all plugins to support it. It makes
> > > > > more sense to provide this functionality using an interface that allow
> > > > > you to push painting of a set of objects to an off-screen surface. Such
> > > > > an interface will likely not be added until other major drawing
> > > > > framework changes are in place but it's definitely something that
> > > > > should be added eventually.
> > > >
> > > > I don't see a reason to do this with offscreen rendering. This still
> > > > wouldn't solve the problem that windows have to be painted in the
> > > > reversed order to make the faces in the background look right. Another
> > > > disadvantage would be that transparent cube would be only supported on
> > > > cards that have offscreen rendering support (fbo's). The only advantage
> > > > would be be that we wouldn't need to redraw each face on each repaint.
> > > > Correct me If I'm wrong here.
> > >
> > > You're right, I don't know what I was thinking of yesterday. Off-screen
> > > rendering is not going to be of much help here. I clearly didn't look at
> > > this closely enough yesterday.
> > >
> > > I think I got a better understanding now and it seems that the BTF / FTB
> > > patch is a solution for some special cases where windows should not be
> > > rendered using their server side stacking order. A more general solution
> > > that makes it possible for plugins to adjust the order in which windows
> > > are rendered would make more sense to me.
> > >
> > > Here's a suggestion:
> > >
> > > Instead of just walking the list of windows when rendering them like
> > > this:
> > >
> > > for (w = s->window; w; w = w->next)
> > >
> > > we can do something like this:
> > >
> > > for (w = (*s->stackFuncs.first) (s); w; w = (*s->stackFuncs.next) (w))
> > >
> > > and the core version of "stackFuncs.next" would just look like this:
> > >
> > > CompWindow *
> > > stackNext (CompWindow *w)
> > > {
> > >     return w->next;
> > > }
> > >
> > > plugins can provide any stacking order they want when rendering windows
> > > by wrapping the stackFuncs struct with it's own stack functions. This
> > > should be good for transparent cube and things similar to what the 3d
> > > plugin is doing, right?
> > >
> > > What do you guys think? My biggest concern with the BTF / FTB patch is
> > > the way the screen can first be painted with BTF order and then with FTB
> > > order and some plugin must then prevent the core from painting the
> > > window twice.
> > >
> > > - David
> >
> > Great idea but we also should have stackFuncs.last and prev to do the
> > occlusion detection right and maybe a MASK to be able to disable the
> > occlusion detection.
>
> yes, .last and .prev are in that struct too of course.
>
> >
> > This should be enough to realize transparent cube and most parts of the 3d
> > plugin.
> >
> > The last point we should look here are the wrapable clipping planes patches. I
> > think the attached picture describes what we have now and what we would like
> > to have. Sorry but I'm a very bad painter ;-)
>
> yes, I know what you mean. I'm trying to figure out what's the best
> solution here. Maybe it's to add the clip planes as arguments to
> paintTransformedScreen function. I'm not sure.
>
> - David
>
> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>