[compiz] Re: [PATCH] Transparent cube

[David Reveman]

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=36ca8bf25
> > >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