Posted on

Next generation OpenGL compositing in 4.6

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:

  1. Mobile edition: port compositing stack to OpenGL ES 1.1 and/or 2.0
  2. Improve performance: render less, render faster and more frames per seconds during animations
  3. 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

Posted on

Blacklisting drivers for some KWin effects

This is mostly a post for our distributions. In 4.5 we will most likely activate the Blur effect and Lanczos filter for Taskbar Thumbnails and Present Windows by default. Unfortunately not each driver supports those correctly. We have the following possible problems:

  • Performance issues with Blur Effect
  • Upside-Down taskbar thumbnails with Lanczos filter (affects also Present Windows)
  • Too bright taskbar thumbnails with Lanczos filter (affects also Present Windows)
  • Performance issues with Lanczos filter in Present Windows

Most users won’t have problems with those two new or if there are problems they affect only one of the two. E.g. disabling blur for performance does not require to disable the Lanczos filter. Therefore I implemented a KConfig based blacklist during Akademy. It uses KWin’s default KConfig file (~/.kde[4]+/share/config/kwinrc) and uses KConfigGroup "[Blacklist]". The blur effect uses the sub-group "[Blur]", while the Lanczos filter uses the sub-group "[Lanczos]". This might be extended in future releases.

The blacklist is implemented in a way that specific driver versions for specific hardware are blacklisted. So if a new driver version is released this one won’t be blacklisted automatically in the hope that the new driver version fixes the issues (e.g. it is known that the upside-down issue is already resolved in Mesa master). On the other hand this means that if a problem is not fixed it will occur for the user as soon as the new version is installed. Which will of course cause problems and users will claim that $distribution is harming KDE because of $stupid thing.

The blacklist can be updated by a KConf update script and that’s the way we will ship a default blacklist in 4.5 (this is currently not yet implemented as we still collect information on drivers causing the problems). So if you as a distribution are informed about a problem with a specific driver please pass the information to me, so that I can update the blacklist for the final or minor release and (after the release) please ship a kconfig update script to change the blacklist. This is especially important if you update the drivers (e.g. a development release). Although I have no idea how to automatically update the blacklist if a user is getting the drivers from e.g. xorg-edgers PPA (btw this seems to cause quite some crashers).

The entries of the blacklist are normal KConfig entries with driver identifier as key (e.g. Intel or NVIDIA) and a list of strings for the values. Each list item is a concrete identifier for a combination of renderer and version separated by colon, dash, colon (:-:). Renderer and version can be read from glxinfo. Here an example blacklist:

[Blacklist][Blur]
NVIDIA=GeForce 9400M/PCI/SSE2:-:3.2.0 NVIDIA 195.36.24

[Blacklist][Lanczos]
NVIDIA=GeForce 9400M/PCI/SSE2:-:3.2.0 NVIDIA 195.36.24

Which will block my GPU on both blur effect and lanczos filter (which is of course not required). I will update the blogpost with link to the kconf update script as soon as it is implemented.

=-=-=-=-=
Powered by Blogilo

Posted on

Web content embedded in KWin effects

Those who attended my talk about KWin Mobile at Akademy could see the new KWin effect which demonstrated that it is possible to embed web content in a KWin effect. Unfortunately nobody could see the highlight of the effect as Germany scored too early and too late. If somebody scored a goal a nice animation would have been shown. I just modified the effect to show the animation on startup to be able to record it. As always: sorry for the bad quality – recordmydesktop does not like me.

Direct download as ogv

And yes the effect is called "Kicker", as it connects to kicker.de to get the current score and in remembrance to a well known panel I kept the name. The effect is quite simple and is just something like 200 lines of code and it took me only one hour (first half of match Spain vs Chile plus the half time – yes I was confident that Germany will have a match during my talk) to implement the parsing of the current score and displaying it on the screen.

Each half a minute the effect connects to the remote site and downloads the html file. Using QtWebKit and some small reverse engineering it extracts the names of the two playing teams and the current score. These strings are combined and put into an "EffectFrame" – our high level API for displaying Plasma styled textures on the screen – and shown on each screen.

The effect also caches the current score and compares it with the previous one. If it changed we know that someone scored a goal and the animation is triggered. This animation (as seen above) uses another EffectFrame, but this time an unstyled. The animation will stop after seven seconds. In that duration the texture’s opacity value is constantly increasing and decreasing, so that you have a flash event. We have a high level API for that as well: KWin::TimeLine which wrapps QTimeLine in an API tainted for the usage in KWin effects.

The code is of course useless for KWin trunk as it is a really special feature and I don’t like the QtWebKit dependency in the effect library. Nevertheless I will import the code into our test directory as it is a nice example on how to use the EffectFrame and really showing how flexible our effect library is.

=-=-=-=-=
Powered by Blogilo