Posted on

KWin a solution for non-KDE based Desktop Environments?

Recently I have seen more comments about using KWin as a stand-alone window manager in other desktop environments. It looks like quite some users are looking for a replacement for Compiz nowadays. But of course especially among the users of the lightweight desktops there is the perception that one cannot use KWin because it is done by KDE.

So I thought I spent some time on explaining about what it actually means. Of course KWin is the window manager of the KDE Plasma workspaces. And this means it is part of the KDE source code module called “kde-workspace”. Most distributions provide one package or a set of packages which depend on each other for this workspace module. This means to install KWin one has to install what people consider to be “KDE”. But it doesn’t mean that one has to run any other part of the kde-workspaces. KWin is a standalone application which only depends on the kde libraries and requires a few runtime modules (e.g. the globalshortcuts daemon or kcmshell4). One does not have to run the Plasma desktop shell or systemsettings or any other application provided by the KDE community.

So installing KWin requires to install a few more applications, but all they will do is take up some space on your hard disk. I know that people are sometimes very concerned about it, so I run “du -h” on my kde install directory. This includes not just the kde-workspace module with its dependencies, but more or less everything we have in KDE’s git repository including things like an office suite, IDE, webbrowser, artwork and many other things one doesn’t need to run a window manager 😉 The result of all that is just 13 GB of disk usage. Given current storage costs (0.06 EUR/GB) this costs less than 1 EUR which is less than a cup of coffee where I live. And remember KWin will need less storage. The bare kde-window-manager package in Debian is just around 10 MB.

I understand that people care about the dependencies and think this is important. I just don’t think it’s of any importance in a world where a movie needs significantly more data storage. Still we care about the dependencies and we are working on breaking down the dependency chain as part of the frameworks modularization efforts. One of the results of this is that we have documented dependencies nowadays. And we are working on getting the dependency to the Plasma framework as a runtime-only dependency over QtQuick, so that people can put together themeing for KWin which does not pull in any bits of the Plasma dependency. Help on that is appreciated 🙂

A more relevant issue is the question of memory usage due to running KWin. Unlike disk storage, memory storage is still rather constraint. Unfortunately it’s very difficult to provide correct measurements on the memory usage of a single KDE application. KDE applications have many shared libraries (e.g. Qt). So if KWin is the only Qt application, the relative memory usage is higher than when using several Qt applications as for example in LXDE on Qt.

Now a few highly non-scientific numbers: according to KSysGuard my self-compiled KWin (Qt4) uses around 40 MB of private memory and 38 MB of shared libraries (Qt, kdelibs, XLib, xcb, etc.). The memory usage also depends on what you use. If you activate the desktop cube effect with a 10 MB wallpaper put in the background, you will see this in the memory usage 😉 Just as another value for comparison: the iceweasel instance I’m writing this blog post in has a private memory usage of more than 700 MB. Of course KWin is with that in a different league than the minimalistic window managers, but one has to see that KWin provides more features and is a window manager and compositor. If one needs to run two applications to get close to the same feature set, it’s quite likely that the same amount of memory is needed. KWin has many features and there is no such thing as free-lunch in IT. It’s certainly possible to trim KWin down by not loading the KWin effects and ensuring that no scripts are loaded and simplified graphics.

Given that I can only recommend to give KWin a try and not to discard it because it is from KDE and might pull in some dependencies. Evaluate by the features we provide and you want to use and not by some random number on your hard disk or your memory usage.

Posted on

KWin/5, QtQuick 2 and the caused changes for OpenGL

In the KWin/4 days our OpenGL implementation could be based on some assumptions. First of all only KWin creates an OpenGL context, none of the libraries, KWin depends on, uses OpenGL. From this it is possible to derive more assumptions, for example our compositing OpenGL context is always current. Which means that it’s possible to run any OpenGL code in any effect. No matter how the code path got triggered. Also we can link KWin against OpenGL or OpenGL ES. We don’t have to check with other libraries to prevent conflicts.

With KWin/5 these assumptions no longer hold. KWin uses QtQuick 2 and with that we pull in the Qt OpenGL module. One of the direct implications of this change is, that we are no longer able to provide kwin/OpenGL and kwin/OpenGLES at the same time. The compilation of KWin has to follow the compilation of the Qt OpenGL module. So compiling against OpenGLES is only possible if Qt is compiled for OpenGLES, which means that the option to run KWin on OpenGLES is probably non-existing on classic desktop computers and the option to run KWin on OpenGL is probably non-existing on ARM systems such as the Improv. Given that it’s no longer possible to compile both versions at the same time, the binary kwin_gles got removed. A kwin compiled against GLES is just called kwin.

With QtQuick also our assumption that only KWin creates an OpenGL context and makes it current doesn’t hold any more. In fact it could be that at any time Qt creates an OpenGL context and makes it current in the main GUI thread. Now people probably know that QtQuick 2 uses a rendering thread, so that should be fine, right? Well not quite. To decide whether QtQuick uses a rendering thread it creates a dummy context in the main gui thread and makes it current. So our assumption that our context is created once and then kept current, doesn’t hold any more. The first solution to this problem was to make our context current whenever we go into the repaint loop. That worked quite well, till I tested KWin/5 on my SandyBridge notebook.

The problem I stumbled upon is that Qt doesn’t use a rendering thread in all cases. For some hardware it prefers to use the main gui thread. One of them is SandyBridge Mobile, the hardware I am using on my notebook. This showed that the initial solution was not elaborated enough. With another context rendering in the same thread it showed that it’s quite likely that we hit conditions where our compositing context is not current. Resulting in e.g. not rendered window decorations, effects not able to load their textures, etc. etc.

These problems are hopefully solved, now. The effects API is extended by calls to make the context current and I tried to hunt down all effects which do OpenGL calls outside the repaint loop. Unfortunately given the large number of effects it’s still possible that some effects use it incorrectly. It will be difficult to track those down: so please test.

The case when QtQuick uses the main GUI thread for rendering illustrates that we in KWin are not the only ones having incorrect assumptions on OpenGL. QOpenGLContext assumes that every OpenGL context in a Qt application has been created through QOpenGLContext and that an OpenGL context is only made current on the current thread through the QOpenGLContext API. Especially if one uses glx or egl directly to make a context current QOpenGLContext doesn’t notice this and assumes that its own context is still current which can result in nastiness. This is circumvented in KWin now by making sure that QOpenGLContext has correct information once the compositing context is made current. Nevertheless we are still hitting a bug causing a crash. This one is also currently worked around in the development version by enforcing XRender based compositing on the hardware which uses the main GUI thread for rendering. On SandyBridge one can also use the environment variable QT_OPENGL_NO_SANITY_CHECK to force QtQuick to use a dedicated rendering thread as the problem why Qt uses the main gui thread is not relevant to KWin’s usage of QtQuick. KWin also checks for this environment variable and doesn’t force to XRender, if it is set.

Obviously one could question why we are not using QOpenGLContext given that this seems to conflict. We haven’t used Qt’s OpenGL module mostly for historic reasons. Of course I evaluated the option of using QOpenGLContext when investigating this issue and right now in Qt 5.2 it would not be an appropriate solution for the usage in KWin. It’s not possible to create a QOpenGLContext from a native context and even if it were possible our implementation is more flexible. KWin can be compiled against both egl and glx allowing to switch through an environment variable. Qt on the other hand supports either egl or glx, but not both at the same time. If I find time for this, I intend to improve the situation for Qt 5.3, so that we can consider the usage of QOpenGLContext once we depend on Qt 5.3. Switching to Qt’s OpenGL context wrapper would allow us to get rid of a considerable amount of code. I’m especially interested in the QOpenGLFunctions. Obviously that will only be a solution if KWin uses the same windowing system as Qt’s platform plugin. But that’s a problem for another day 😉

Posted on

KWin/5 open for bug reports

Today I added a new version number to our bugtracker: 4.90.1. This is the version number currently used by KWin on Qt 5 and this means that I consider KWin/5 to have reached a quality level where I think it makes sense to start reporting bugs.

On my system KWin/5 has become the window manager I use for managing the windows needed for developing said window manager. The stability is already really good and today I fixed one last annoying crash when restarting KWin. So I’m already quite happy. Also the functionality looks good. Some of the problems I had seen and been annoyed by are fixed and this means that my normal workflow is working. But KWin supports more than the “Martin workflow” and this means you have to test it and report bugs! Grab the latest daily build packages for your distro and enjoy the power of a Qt 5 based window manager.

Posted on

Color Scheme syncing between window and it’s decoration

Some time ago I started Krita and I had the thought: well we can do better. The window decoration is just looking out of place. Everything is a nice dark color, but the window decoration isn’t. So I asked a few people what they think about making it better and the reaction was overall very positive and I started to investigate.

Right now I have a solution for KWin/5 which allows the window decoration to follow the color scheme of the window. Have a video:

At the moment it’s implemented mostly inside Oxygen, but I intend to move most of it to KColorScheme an KStyle directly, so that any KDE/Qt application can benefit from this new feature.

And of course I need to point out that all of that is possible without opening Pandora’s box of Client Side Window Decorations as Aaron said today.