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
do you think that one of the main advantages of the whole kde project that almost every little piece is interoperable and can be used independently on other desktop shells, with other windowmanagers, in different ways, etc., etc. could become a disadvantage in the future..
maybe this idea of portability – the wish to produce something that works in many different usecases on many different plattforms is a big problem and it would be better to concentrate on one thing and one thing only that only works under a reasonable number of circumstances.. (a little bit like apple does it)
“having Desktop Shell and Compositor in one process and one rendering graph” sounds like it could provide a better and faster user experience.. (and maybe less work to maintain) who cares if it only works with gnome shell an is incompatible to the rest of the world anyway?
just for the record.. i really like the kde way and i think it is superior (like kde-telepathy is so much more than just another telepathy-cilent like empathy)
i’m just thinking…..
no I don’t think it is a disadvantage but an advantage. Just consider that through the right abstraction layers we are able to provide different shells for different form factors.
Hi Martin,
Your Blog posts are very interesting and informative, especially it deals with really complex topic of graphics/drivers/X etc.
I would be really curious to know how GNOME Devs explain the constant need for compositing even when people are watching HD full screen videos or playing games?
Please do share your discussions with them and their solutions.
Cheers!
The last paragraph looks like some serious unification proposal! So Plasmoids might become Windows (or be identical with Windows in the sense that they both will be managed by the Compositor with little to no difference between them, and the Compositor knowing nothing about that?)
And one more question, how is the Qt Scene Graph related to the Scene Graphs you’re discussing here? I’d really love to know that. They’re called the same, but…
P.S. I’m missing this GSOC due to real life… I sincerely hope that the next one will be mine 🙂
I don’t see me saying anything like that and I did not propose anything.
…but are not the same. The QtSceneGraph is a scene graph for QML but not an universal scene graph.
You are ofcourse welcome to work on non-GSOC parts of KWin. I hope to write a blog post on what I would like to see in KWin the next few months to be implemented.
I am really glad that GNOME makes such intense use of 3D. With big players like novell and redhat using it for building their products this will hopefully improve the situation of graphics drivers soon. Lokking forward to the day nvidia simply wont be able to ship a non KMS non gallium driver and support nouveau or improve their blob.
The new shell has some really cool ideas, some of them should be considered for kde integration. For example the dynamic creation of virtual desktops is way more elegant than the plus and minus buttons in kwin.
And of course having a mature, and visible search function (i bet max 5 percent of all kde users know about krunner…) rocks, especially when zeitgeist gets finally integrated.
Plus and minus buttons in KWin FTW! It’s much better that way. Try to assign the Desktop Grid to a key and use that; minus/plus buttons are delightful to use specially if you have a touchscreen.
The realist in me says that this will happen on the day when hell frozes over.
Please don’t require kwin to run KDE! In my setup I run xmonad as the $KDEWM, as it does a much better job as a tiling window manager than kwin (I tried switching once, but quickly went back to xmonad). I love the KDE environment and the KDE apps, but I find that a tiling window manager works much better for my (very keyboard-centric) workflow than using a compositing window manager like kwin. Also, my poor laptop handles it better. 🙂
There are no intermediate plans for a KWin dependency and also no need for it. The situation changes with Wayland, though in general I doubt that xmonad will be ported to Wayland.
Martin , thank you for being such an open minded Kde developer! Ever interisting to read!
I had some fears over missing shadows some week ago. But now I see:
– wonderful having shadows from window decorations, because
– there are no menu shadows any more.
Because I don’t want menu shadows. I want windows shodowing for oversight of my cluttered desktop.
Keep going …
I am sorry, but menu shadows are back, but not yet merged into master.
crabman, you really want dynamically destroyed my personal plasma workspaces? And never be able to push a window behind borders in a free desktop?
1. I didn’t know about how KWin and Compiz are related. Kudos for the Compiz team, always open to contribute and help, and specially to smspillaz, who seems to manage all the Compiz-KWin collaboration efforts.
2. From your post, I see the communication between Mutter developers and Compiz/KWin has been less than the communication you can expect to have with Microsoft DWM: zero. GNOME has to do serious efforts to improve the communication.
Time will tell what will happen with clutter/mutter after gnome3 release. But yes, now we have most mainstream DEs backed by a compositing WM. Interesting times ahead.. 🙂
“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?”
Well nothing prevents us from doing so … clutter is open source 😉 When we hit lower level bugs in clutter we fix them there or at least try to get the clutter people to look at the problems and get them fixed which works very well.
“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 should be the last resort … you should try to get in touch with the driver people and get the issues fixed first. Which is what we did while developing mutter/GS … when we encountered driver bugs we talked to the driver people to try to get them fixed there instead of just adding workarounds in the code.
“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.”
Your conclusion is wrong here … it isn’t that you “don’t want compositing” but that you “want to find out whats wrong and fix the bug”.
The last two statements might sound odd for people with a pragmatic pov “it has to work now” but longer term the goal should be to fix the problems at the root and not try to deal with the symptoms.
thanks for your reply.
If that would work, it would be great. But reality looks unfortunately different. I believe you that it worked for mutter/GS so far as you did not have a release. But if you have a release and notice later on that a new driver version has been released which breaks your code (as that was what happened with 4.5) there is nothing we can solve with talking to the driver devs.
How to fix bugs in the ATI blob which I have to use as radeon doesn’t work? Reality looks different.
basically what you say is that a bug fix is better than a workaround.. nothing wrong with that..
but you have to admit that there are hundreds of situations where a workaround is quite useful until the bug is fixed.. (sometimes you just can’t wait for other people to do their homework)
just because you provide some workarounds this does not mean you do not want the reason for the workarounds fixed anymore..
Time will tell, but didn’t gnomeshell switch to compiz for window management? I just installed gnome-shell in ubuntu, and it didn’t install mutter but kept compiz as the window manager. There’s at least one thing in favor of GS it seems a lot snappier (but a hell of a lot less capable) than plasma+kwin.
No, it’s Unity that switched from Mutter to Compiz.
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?
That *would* be interesting, but it’s not 100% true. They can’t entirely change the rendering to suit, but as significant contributors to Clutter, the Mutter developers can make upstream changes fairly freely…
KDE finger – multitouch – oriented GUI.
I do like KDE, but GNOME2 GUI is my favorite and even Unity and Gnome3 – very similar GUIs – are “easier” ways of interacting with the computer for me.
I know you are writing about inside matters, but i think KDE should have a multitouch GUI TOO similar to Unity and Gnome3 in order to be installed on tablets and in multitouch desktop computers. And Gnome3 the ability to choose “old style” GUI.
And of course Unity and Gnome3 has a lot o issues to solve with drivers, ATI, at least do not work properly with both of them, but I expect this 3 wiill evolve.
About inside matters, I think kronos must upgrade opengl to catch directx, and open desktops use opengl better.