[compiz] Re: [PATCH] Transparent cube

[Dennis Kasprzyk]

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.

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 ;-)

Dennis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clipplanes.jpg
Type: image/jpeg
Size: 46210 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20070427/585c9d2f/clipplanes-0001.jpg