With the release of GNOME 3 the third major Window Manager (Metacity) entered the field of OpenGL based compositing in the incarnation of Mutter. Congratulations! Now I know some will say that Mutter was around before, but with GNOME 3 it’s the first release for a non-niche product like Moblin and Unity (10.10) and is targeting desktop computers as well. I hope to find the time to play around with GNOME Shell a little bit. I wanted to try some weeks ago but even on my Intel system I only got the fallback mode 🙁
Personally I am very interested in some of the aspects of Mutter and I am eager to see how Mutter will perform under the new conditions it will be put through by the users. While KWin and Compiz are very similar using C++ and OpenGL directly, Mutter is very different. As the name implies it uses Clutter as a scene graph. So instead of directly transforming the scene with OpenGL, Mutter uses an abstraction library wich does not directly map the OpenGL semantics.
Internally KWin also has it’s own scene graph, which allows us to write Effects without any knowledge of OpenGL. So for example Present Windows uses only the built-in functionality to translate and scale windows and the same code base works with all our compositing backends: XRender, OpenGL 1.x, OpenGL 2.x/OpenGL ES 2.0. The rendering itself is done using our own custom OpenGL code. Compiz is from the architecture very similar which allows us to share ideas and sometimes even code (Compiz and KWin are much closer as you might think, for example we have the same perspective projection matrix). Sharing more than ideas with Mutter/GNOME Shell seems to be impossible, unfortunatelly.
Given my own experience I know that introducing a new OpenGL compositor can be difficult. It takes time till you know all the required quirks for all the various hardware and drivers and it takes many bug reports to learn about them. Here I am very interested to see how Mutter will perform as the compositing is based on an existing OpenGL abstraction layer. Will they hit the same problems as we did and if yes how will they be able to deal with them given that they cannot change the rendering code directly? KWin has learned a lot about drivers during the last year and nowadays we can go down to disable specific features based on hardware chips, drivers and versions. This allows us to tackle severe issues even in minor revisions.
Another point I’m interested in is the usage of a scene graph library in general. KWin’s internal scene graph is tamed to the needs of an OpenGL compositor. On the other hand Clutter is a general purpose scene graph not only developed for compositors. Of course you would expect that Clutter’s OpenGL is better given that the developers are only working on OpenGL and do not need to maintain a window manager. But a compositor is very different to all other applications. For us the most important part is the texture from pixmap operation, which is hardly needed by non-compositors. But advanced OpenGL functionality is hardly required in an compositor: KWin for example does not use a z-buffer or stencil buffers.
As indicated in my last blog post
I would like to be able to always enable compositing for all users. Here I want to thank all people who commented on the post – this is highly appreciated and the feedback will be evaluated. Now Mutter or in fact GNOME Shell is a step ahead: they require compositing. But as I also outlined in my last post there are situations where you don’t want to have compositing – and I know what I’m talking about: my primary system does not wake up from suspend if compositing is enabled. I am really interested in seeing how Mutter handles such situations where you actually don’t want compositing and I hope to learn from them in these aspects. I am really looking forward to talk about such issues at Desktop Summit with the Mutter developers.
The last important point I will study with the advance of Mutter (and also Unity) is the tight integration of Compositor and Desktop Shell. In the KDE Plasma Workspaces Compositor and Desktop Shell are two separate processes which allows to use KWin with any Desktop Shell (excluding GNOME Shell and Unity) and Plasma with any Window Manager (with or without compositing support). Given the new development of missing interoperability between desktop shells, keeping the option to use a different window manager becomes less important. In fact with Wayland it might even be stupid to not have the desktop shell (and many other parts) in the compositor and switching compositors might be impossible at all. I really want to know about the advantages of having Desktop Shell and Compositor in one process and one rendering graph. There are many aspects in Plasma which can be done better in the compositor and we already make use of it – like the sliding popus, but there is much more. This is btw. a wonderful way to get involved with KDE development 🙂
Powered by Blogilo