[compiz] Re: [PATCH] Transparent cube

[David Reveman]

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