On Mon, Dec 13, 2010 at 6:24 PM, Owen Taylor <[email protected]> wrote: > So, one of the primary effects in the GNOME Shell user experience is to > take a stack of windows: > > +---------------+ > | |+ > | ||+ > | ||| > | ||| > +---------------+|| > +---------------+| > +---------------+ > > And animate them zooming out and spreading apart to: > > +---------+ +---------+ +---------+ > | | | | | | > | | | | | | > +---------+ +---------+ +---------+ > > This is surprisingly GPU intensive - say if you have a stack of 8 > fullscreen 1920x1200 windows - not a weird situation - then at the > beginning you are drawing: > > 8 * 1920 * 1200 * 60 = 1.1Gpix/sec
Right, this is a tricky issue that pops its head up every now and then; we've also had others come and ask similar questions. I think quite a lot of applications would like to take better advantage of the depth buffer to avoid overdraw. The "renderlist" work that we started designing a while back was meant to take us in a direction that would let Clutter be able to automatically use the depth buffer to avoid overdraw of actors with no work from the application. Ref: http://wiki.clutter-project.org/wiki/Cogl_Render_Lists I think that the renderlist needs some further design iterations, but actually at the low level Neil and I have been slowly putting the building-blocks into Cogl to enable us to take another pass at this. I think perhaps we can find a shorter term solution for gnome-shell, but it would be good to to have more input into a longer term renderlist like approach too. > > Which is beyond the capability of integrated graphics and even off > low-end discrete cards. The obvious win here is to use the depth buffer > to greatly reduce the amount of work we need to do per pixel - to cut > out perspective divison and texture fetches and writes when texturing. > > But I don't actually want to do deal with a 3D scene graph, I want to be > able to specify x/y coordinates for a window and have it appear at those > coordinates and have the z coordinates *only* be used for depth > clipping. > > I'm not really sure about the best way to achieve this with Clutter and > would appreciate suggestions. Ideas: > > * Switch the stage over to an orthogonal transformation. Other than > maybe actually wanting perspective effects for something in the > future the only disadvantage I know of is that (last I checked) > there is no API in Clutter to do this and you have to resort to bad > hacks like connecting to ::paint on the stage. Something we've been discussing more and more recently is adding a ClutterCamera object which would own the perspective and view transforms + the viewport transform and be associated with a framebuffer. A stage could be associated with a list of cameras, and for compatibility there would be a "default" camera which is associated with any new stage. For your use case you could then get a-hold of the default camera and change the projection matrix to be orthographic. As tomas mentioned I also think perhaps it would be a shame to constrain gnome-shell to an orthographic projection and maybe instead look for a solution that doesn't depend on this approach. > > * Make the Window actor (a custom actor) munge the x/y coordinates > when painting with Cogl so after the perspective transform the x/y > coordinates are the same independent of Z. > > * Use a vertex shader to adjust the z coordinates after the perspective > transform. Right, this is what we would have been doing with the renderlist approach. After projecting the users geometry we would have replaced the z with the painter's algorithm z and painted opaque geometry front to back. So I guess the idea would be to use the cogl shader API to create a glsl or arbfp vertex shader which can be associated with the materials used by your window actors. (I wouldn't recommend using the Clutter actor set shader mechanism for this.) Somehow then there needs to be some interaction between the container that knows the stacking order of the windows and the window actors so that the stacking-z gets set as a uniform on the shaders. One concern I have a.t.m is that we probably don't track custom uniforms in a useful way a.t.m and likely you will end up with the same program associated with all of your windows and when you change the uniform for each window you'll in fact just end up changing the uniform on the same program and then when you draw all windows will end up with the same stacking-z. I wonder if we need to move the ownership of uniforms from CoglProgram into CoglMaterial. So I suppose when your window container paints it would: 1) clear the Z for the bounds of the container (send a quad with z = 0 using a material with depth writing enabled, depth testing disabled) 2) paint opaque windows front to back (all with a special material including the vertex program + with depth writing/testing enabled) 3) paint semi-transparent windows back to front (also with a special material including the vertex program + depth testing enabled) Note: for now you'll probably need to use the COGL_ENABLE_EXPERIMENTAL_API define to get the required control over the depth writing/testing state, beyond the deprecated cogl_set_depth_test_enabled function. > > Any other ideas that I'm missing? window containers could potentially build a mask up in the stencil buffer as windows are drawn so stencil testing could be used to avoid overdraw. This would rely on your container being able to do the depth sorting and painting front to back. This approach wouldn't support semi-transparent windows though. kind regards, - Robert P.S sorry if I don't respond to this topic much in the coming weeks as I'm currently on holiday. > > - Owen > > > _______________________________________________ > clutter-app-devel-list mailing list > [email protected] > http://lists.clutter-project.org/listinfo/clutter-app-devel-list > _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
