Hi David. I was just writing a post now, trying to explain too why offscreen rendering won't help us on this case, and got your new mail while writing it, so here I start again... ;-)
I think your new suggestion is quite interesting, it sure is more general than BTF / FTB, although I personally don't see any useful painting orders except BTF / FTB (of course, the fact that I personally can't find any doesn't mean there aren't any). More generic solutions are mostly better, and this is why I prefer your way over mine, although implementing 3d in this way will really be harder. I volunteer for trying to implement your interface and making both 3d and cube use this interface if you are interested. What do you think of all the other patches? Do they look okay? Thanks, Roi. On 4/27/07, David Reveman <[EMAIL PROTECTED]> wrote:
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
_______________________________________________ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
