In this blog post I want to give an overview on what I am planning and working on for KWin in KDE SC 4.6. The big topic for 4.6 is performance – in 4.5 we introduced the blur effect and our designers want to extend the usage of blur to all windows. This is currently not yet recommendable (yes there are widget styles on kde-look which offer this function, but KWin is not ready for it!), so we have to work on it.
In general there are three topics I will address in the next cycle:
- Mobile edition: port compositing stack to OpenGL ES 1.1 and/or 2.0
- Improve performance: render less, render faster and more frames per seconds during animations
- Stabilize the effect ABI to be able to provide BC latest in 4.7 (if it makes sense)
These three topics are very much related to each other. For a mobile port we need to improve the performance and port to OpenGL ES. This requires to cleanup the rendering code which gives us a more modern rendering code resulting (in theory (I do not trust drivers any more)) in better performance (render less and faster). As part of this I am aiming to use forward-compatible OpenGL Shaders by default for rendering. Yesterday OpenGL 4.1 was released and it would be nice to be able to use OpenGL 2 functionality in a real world application on Linux. So this is an urge to the driver developers: please get your drivers ready for 4.6 – we will stress them. In a next step I want to go to OpenGL 3 in 4.7, but the free drivers do not yet support this generation. (That’s perhaps a point to work together with Compiz developers)
Thanks to the improvements on the rendering stack our API gets into a state where it makes sense to think about guaranteeing BC. Currently we do not and break the ABI in each cycle several times (up to now I broke BC in trunk more than five times). Our API does not yet use d-pointers and we have many pure virtual classes, which will make it difficult. But the API itself has not changed much during the last cycles, so it’s pretty stable already. With 4.6 the compositing stack will have been used three years, with two years enabled by default, so it’s really time to think about it. But this is just an idea I have and is not yet discussed with other KWin developers and it will require lots of boring work.
So where are we? I started with improving the rendering code of our Plasma styled frames and moved the rendering code into the concrete implementations for XRender and OpenGL. That made it possible to get something like the following screenshot:
Boxswitch with blurred background
Also the rendering code is improved. Instead of recreating the icons in each rendered frame by doing a QPixmap -> QImage -> GLTexture conversation, the icon texture is reused and generated using Texture From Pixmap (TFP) as used for our window pixmaps (there are still some effects forcing a recreating in each frame, but this will soon be fixed). For passing the geometry to the GPU a vertex buffer object (VBO) is used instead of the very, very old glBegin/glEnd. This VBO is also cached, so each geometry is only created once and passed to the GPU once. My abstraction for VBO is able to fall back to legacy rendering if VBOs are not available (very unlikely), which gives us just one high level API call to do legacy, normal and modern (forward compatible) rendering. The old methods are deprecated although still used by the window rendering (this requires some more useful changes as they currently stream the vertices in each frame). For rendering the effect frames (and all other textures) triangles are now used instead of quads (unavailable on ES and OpenGL 3 forward compatible profiles).
And what next? We still have many things to improve. Especially window rendering has to be changed to cache the geometries (when it makes sense) and the clip regions. The clip regions are one of the reasons why I want to switch to Shaders (other reasons are Nuno’s wishes for effects – if you want to work on awesome effects get in touch with one of us). The API still needs some more cleanup and our compositing stack has to be split into parts for GLX and EGL. Nevertheless I think the API is already in a state where I think of daring to compile KWin effect library this weekend on Maemo to see what breaks (effects would not yet compile).
Powered by Blogilo
19 Replies to “Next generation OpenGL compositing in 4.6”
It’s almost routine for KWin by now, but this is really extraordinarily awesome stuff 🙂
Freezing the ABI sounds dangerous, though. A pet peeve of mine is the fact that objects of the Deleted class (still!) aren’t part of the regular stacking_order – which means that windows that are fading out, for example, are always on top of all other windows even if they were below before they were closed. Wouldn’t such stuff be set in stone when the ABI is fixed?
No freezing the ABI would not hinder us to fix the bug. In fact the effect library does not really know that a windo is of type Deleted. This is part of the core and the bug fix would not change anything in core (but is difficult to fix – I had a look at the code. In fact I myself reported the bug).
Thank you for your answer, that’s a relief.
(I already knew this bug would be hard to fix, so no disappointment there.)
This kind of blog post talks about stuff that overall excites me the most: technical graphics stuff on the desktop. I’d be interested in what you guys think about the situation of Qt’s graphicssystems. I’m asking because when I tried the “raster”, software-only graphicssystem, the desktop felt more responsive and applications like rekonq could scroll a lot faster/smoother. So the x11 graphicssystem (default) really makes KDE4 look slower than it is and I haven’t heard if the new OpenGL graphicssystem will be done anytime soon.
What I would like to see is that a 3d composited desktop being faster than 2d. That must be possible given the speed of the GPU’s these days. I always end up turning 3d compositing off because I cant live with the slow resize of windows, and odd pauses that appear.
I really hope a cleanup/optimization of the rendering will make the switch to 3d a faster expericence 🙂
PS: keep up the good work, and posts about the progress !
It would help if Qt actually used XRender in a decent way.
Like GTK+/Cairo, for example…
Qt’s OpenGL based backends are quite broken, too, unfortunately.
Awesome blog post! This is the sort of blogs I like very much 🙂 Technical details about KDE development – keep it up!
Awesome stuff, keep up the good work! 🙂 Just wondering, will kwin be switching from xlib to xcb like compiz uses?
Maybe I’m misinterpreting things but it feels like the UI is blocking when I for example scroll in firefox and there’s a noticeable delay where no other window is responsive while firefox is scrolling. This gets worse the more windows are open. (Ubuntu 10.04, open source radeon driver for a 4670)
it is not planned and I doubt it’s worth the effort to rewrite great parts of kwin
Thanks for the reply, just curious as a number of blogs and posts by xorg developers extol the benefits of the ‘more modern’ and asynchronous xcb instead of xlib; would it really not improve responsiveness measurably outside synthetic benchmarks (especially with many windows open)? and how much work would be required to make the move to xcb if it was worth it? Cheers
AFAIK both GTK and Qt do not use xcb. So I doubt the usefulness of having KWin using xcb.
ich nutze OSX, Win7 und immer wieder KDE (z.b Kubuntu 10.10)
KDE 4 ist für mich das modernste Desktopsystem überhaupt.
Es fehlt wirklich nur noch das endlich endlich die Desktop render Geschwindigkeit “gefixt” wird.
Viel erfolg Martin 🙂
Comments are closed.