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 [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
