Posted on

More Software Compositing

One of the most often repeated misconceptions about Wayland is that it requires hardware acceleration. I would have thought that this issues would have been resolved once the reference compositor, Weston, supported rendering through Pixman. The reason for this misconception is most likely that the earlier versions of Weston required hardware acceleration.

Now KWin in 4.11 introduces the same mistake. Our experimental Wayland support is only available in the OpenGL compositor – even OpenGL ES is not supported (something is broken on my system I cannot start it). I think this is a bad situation. One of the huge advantages of KWin is the exchangeable compositor allowing to switch to software based XRender in case there are no proper drivers available. In fact KWin switches automatically to XRender if it detects a driver which recommends the XRender backend (e.g. software rasterizer).

So last week I started to work on some new Wayland related features and extended the XRender compositor in a way that it renders to a Wayland surface. It’s a pretty simple setup. Our XRender compositor uses an off-screen pixmap for rendering. The adjusted backend uses a pixmap created through XShm, so we get the frame rendered into a shared memory segment. From there we just copy it into a shared memory Wayland buffer to share it with the Wayland compositor. It would be better if we could create the shared Wayland buffer directly from the XShm segment, but I did not see a solution on how to achieve this.

In the end it’s also not really relevant. After all we want to use Wayland and the last thing we want to do on Wayland is using an X11 rendering API for compositing. So we can consider this more as a proof-of-concept and as a task so that I can get more familiar with Wayland 😉 It helped me to improve the code, so it was worth the effort. Even if it is a more academic solution it serves a concrete use-case: KWin uses XRender as a fallback and we can expect that the backend works. Given that we have to enforce compositing in future, it’s good to know that all backends work. The current state of this work can be found in branch kwin/wayland-backend of my clone (note: the link might change in case I force push).

Video on YouTube

If XRender is an academic solution, we are still facing the problem that we lost our software compositor. So I thought I need to also do something about this problem and started to work on a new compositing backend based on QPainter. It’s a quite simple compositor which uses a QImage as the rendering target. The QImage is created directly from the Wayland buffer, so in opposite to the XRender backend we don’t have the needless memory copy from one to another buffer. This is a very interesting compositor as it’s the first part of KWin which has been written from scratch only with Wayland in mind. It doesn’t support X11 (at the moment). This is the first new compositor written in years, so I found some things to improve and which are already under review. And as it was much easier to write a new compositing backend than I expected, I decided to document it in our wiki. It would be totally awesome if someone could have a look at it and write a dedicated compositor for the RaspberryPi 😉 The new compositor can be found in branch kwin/qpainter-scene.

The switch to Wayland does not only affect our software compositors, but compositing in general. So far KWin has always had the possibility to not require compositing. This doesn’t make any sense in a Wayland world. So I needed to teach KWin that we might need to enforce compositing. Of course on X11 we still want to have the option to disable compositing, so the changes only affect the Wayland backend. When starting KWin with the Wayland display environment variable set, KWin will require compositing. Even if it is disabled in the config options it will be enabled. Even more it ignores the shortcut to suspend compositing and options like unredirection of fullscreen windows. But still the backend might fail and in this case KWin is just exiting. There is no need to continue execution if one cannot see the output. This work can be found in branch kwin/enforce-compositing (which also contains all the other mentioned branches).

Posted on

What we did in KWin 4.11

With the release of the 4.11 Beta 1 behind us it’s a good moment to look back on this last half year on development. KWin 4.11 is a very important release for us. As you might have heard at the last Plasma sprint we decided to make 4.11 the last release of the KDE workspaces based on Qt 4. Fear not: the KDE Software Compilation with all it’s great application will see a 4.12 release – at least I have not heard anything else, just the workspaces need some time to do the Qt 5 transition. In addition we want to provide extended bug fix releases for the 4.11 release of the workspaces. So 4.11 is a very important release – being the bridge towards Qt 5.

This is clearly what dominated the development of this release cycle. While porting to Qt 5 is easy in 99 % of the cases, KWin hits the 1 remaining per cent. There are many non-portable X11 specific features in Qt 4 and sometimes I think we used them all and all of them got removed in Qt 5. That’s not a bad thing – in fact I think it’s a good thing. I don’t want to go into detail about the problems we hit and why we used these Qt features in the first place – if you are interested come to my Akademy talk.

In many cases the changes in Qt required to rethink the problem. A good example is that a QPixmap no longer references an XPixmap which we heavily used during rendering the window decorations. This was causing us quite some performance problems with the combination of Qt graphics system raster and the XRender compositor. At the moment I’m running this combination without any noticeable performance difference thanks to the restructuring forced by preparing for Qt 5. Also in the OpenGL case the decoration rendering got quite improved thanks to Fredrik forcing me to improve the proposed changes and also doing some further changes.

Speaking on performance improvements: Fredrik reworked our OpenGL 2 compositor code base and also introduced a new OpenGL 3.1 code path. By default we still use OpenGL 2 with the fallback to OpenGL 1, but one can easily switch. If the hardware doesn’t support OpenGL 3.1 it automatically falls back to OpenGL 2 or OpenGL 1. When running kwin_gles we default to OpenGL ES 3.0 if present otherwise OpenGL ES 2.0 is used.

But that’s not the only change done to the OpenGL compositor. Thomas and Ralf worked on improving our v-sync behavior. There are now multiple strategies one can choose from – this should help to serve all use cases and setups in a better way. Buffer age support has not made it for 4.11 yet, but I’m quite confident that this will end up in the next release.

One of the tasks we continued from 4.10 is the porting to XCB. This also forced us to rethink some of our code. One of the areas which got rewritten because of this is the screen edge handling. It’s now finally multi-screen aware, but still only the four real corners can be configured, corners between screens don’t make much sense. And here with the screen edges we have one of the few user visible changes in KWin: a highlight when approaching the edge. So this hidden feature is finally no longer hidden.

Another small visual change is concerning the outline when using quick tiling/maximizing on screen edges. The outline should now better indicate what area will be covered by the window. Also based on common feedback the moved window is put above the outline. This used to cause problems with dark Plasma themes causing.

The last changes I want to mention are some effects rewritten in JavaScript. This is mostly to improve the maintainability of the code. The JavaScript effect API is optimized for animating windows based on state changes. If I remember correctly the rewritten effects are Dialog Parent, Login, ScaleIn and Translucency. Thanks to Kai Uwe for helping us with these tasks. There are still a lot of effects which would benefit from this work. So get your editor ready 😉

Overall the effects have seen some changes. BoxSwitch effect got finally the kick as the functionality is now completely available in the QML Window Switching functionality. Explosion got the kick as it has been unmaintained and broken for a long time. The Outline is no longer implemented as an effect, but moved back into KWin core. The add/remove desktop button in Desktop Grid and the close window button in Present Windows got reworked with QML and Plasma components – another nice improvement thanks to Qt 5. Present Windows has also an unpopular change: the mouse action for closing a window got removed. But also we have the code ready to rewrite Present Windows and Desktop Grid with QML (a task for next version). The Maximize window effect got a nice improvement in the OpenGL compositor: it cross fades with the previous window texture which removes the up/down scaling which was not looking that nice. Thanks to Aurelien for writing software exposing bugs in KWin which require reworks allowing to implement this feature.

I’m quite sure that I have forgotten to mention many really important changes which we did over the last half year. It’s a long time and after all we changed 666 files with 32516 insertions and 29217 deletions (git diff –shortstat v4.10.0..master — kwin (master being 4a172a9d)) including the changes by scripty.

Posted on

Fanboys in Free Software

Years ago I had a clear political opinion. I was a civil-rights activist. I appreciated freedom and anything limiting freedom was a problem to me. Freedom of speech was one of the most important rights for me. I thought that democracy has to be able to survive radical or insulting opinions. In a democracy any opinion should have a right even if it’s against democracy. I had been a member of the lawsuit against data preservation in Germany. I supported the German Pirate Party during the last election campaign because of a new censorship law. That I became a KDE developer is clearly linked to the fact that it is a free software community.

But over the last years my opinion changed. Nowadays I think that not every opinion needs to be tolerated. I find it completely acceptable to censor certain comments and encourage others to censor, too. What was able to change my opinion in such a radical way? After all I still consider civil rights as extremely important. The answer is simple: Fanboys and trolls.

When one starts to have a blog in free software one learns the hard way that being a relatively good developer means that you get hated. If you achieve something you get attacked, you get insulted, you get called a dictator [1], you get compared to Hitler [2], etc. etc. People say that you need a thick skin if you want to work in free software. I disagree. There shouldn’t be a need to have a thick skin. We are improving the world, we donated lots of our spare time to work on free software, we donate the source code we write for the public good and we are thanked by insults. This is not acceptable! Even if people dislike some specific software or are a great supporter of another software there is no reason to insult the people or the products. It never is! Not even if it is Microsoft or Apple or Google. There is no reason to attack them.

One of the first experiences I made in this regards was blogging about performance improvements. We can see that most users are thankful for the improvements but that there are also direct attacks. These are irrational, why would one attack the person who improved the situation? Why kill the messenger? People tend to discard it as “haters gonna hate”, but is that the answer to the problem? Do we have to tolerate such comments? Do we need to be hated just because we improve software and blog about it? Nowadays I would just delete such comments, that’s the change in my reaction to handle such situations. My skin became thicker over the years, but overall I prefer to have a thin skin as I used to have – it fits my overall character better.

Over the years I started to observe the behavior of the “haters”. For example I noticed that in the time after the release of GNOME Shell and Unity the hate against KDE increased. This was irrational, especially the reasons for the hate. KDE’s software had matured at the time when GNOME Shell and Unity did their release, so why attack KDE then. Yes after 4.0 that was kind of rational, but the attacks had mostly stopped. So why did they start again? I’m nowadays quite sure that if we would go back we would find an increase of attacks against GNOME at the time of 4.0/4.1.

Free software users are very enthusiastic about their used software. One could even say that they are religious about it. Not only that they also create a kind of split between mostly GNOME and KDE community. The decisions to use either KDE Plasma or GNOME Shell are hardly rational. There are emotions involved and used at the rational for why one uses KDE Plasma or GNOME. The software of the other projects is evil and one cannot use it. We tend to call users with such opinions as “fanboys”, but I find this word unsuited, I call them “religious fanatics”. I will explain in more detail why I compare to religion later on.

Now we all know the irrational reasons on why to not use GNOME software. GNOME is removing features, they are “interface Nazis” and don’t care about their users. KDE software on the other hand is ugly, too complex, slow and unstable.

When basing your decisions on irrational reasons it is inevitable that you will face cognitive dissonance. The introduction of GNOME Shell and Unity at the same time are good examples for triggering cognitive dissonance. The fanboys are convinced that GNOME is the best software in the world, but now they are transited to at that time incomplete software breaking their existing workflows and requiring to relearn. Many things are no longer possible. The belief that GNOME is better than KDE software is seriously challenged by the new experience.

One of the solution to solve this cognitive dissonance is to make KDE software worse in comparison to GNOME Shell or Unity. Being convinced that KDE software is still worse than the other software the dissonance is resolved. That is a blog post about performance improvements is a wonderful way to be confirmed that KDE software is slow, a news about fixed bugs is a wonderful way to show that KDE software is unstable. This explains the strong hate against KDE starting with the releases of GNOME Shell and Unity. Fanboys are trying to resolve their cognitive dissonance.

Obviously GNOME Shell and Unity are only an example. We can observe the same kind of cognitive dissonance with KDE fanboys. An example I can observe in regular intervals is that “the next version is much better and solves all problems” whenever a user is reporting about instabilities or other problems. The fact that another user is experiencing problems is challenging the beliefs of the fanboys which can be resolved by stating that the next version resolves it. We can see these comments for each version since 4.1.

Quite recently we could observe the same kind of cognitive dissonance with the Ubuntu fanboys. Mir was a real challenge to anybody who deeply believes that Canonical is doing the right thing all the time. Given that I wrote a few blog posts on that topic I was able to observe how fanboys tried to resolve their cognitive dissonance. My favorites were that I am the reason why free software is failing because I don’t support Mir. Canonical made it quite difficult for their fanboys to resolve the created cognitive dissonance. Of course reasons were provided but those had been shown as wrong very fast. Fanboys tried to resolve the dissonance by coming up with reasons like “development was too slow, someone had to do something”, which didn’t really resolve it as it’s obvious that the development power would have also helped Wayland. Just yesterday I was able to observe a fanboy in my blog comments. “Please re-read it and make it logically sane and spelling error free.” A wonderful example of adjusting the reality by making my arguments invalid because I had a typo in a reply. My argument that we cannot support distro-only solutions got discarded because there is also YaST which is also distro-specific. On a rational view this argument doesn’t make any sense but under the light of resolving cognitive dissonance it makes all the sense in the world. The fact that distro-specific software is a problem is diminished by pointing out other distro-specific software even if doesn’t matter for the argument (we do not depend on YaST).

I consider these fanboys as a threat to free software. By being irrational they harm everyone. They use emotions for something which should not have emotions. They make it difficult to work in free software. In fact it’s not a problem specific to free software, but can be observed overall in IT. Apple is also a good example for such fanboys. But only in free software fanboys can interact directly with developers and spread their harmful behavior. In the proprietary world they are blocked at the marketing department which is trained to work with such situations.

We need to find solutions to the fanboys and one of the solutions I came up with is to block them on my blog posts. I can tolerate trolls as it’s much easier to handle them. But fanboys are only there to harm you to diminish your work so that their world view doesn’t break. And that’s why I call them religious fanatics. They behave exactly the same. Just compare that to Intelligent Design to resolve the cognitive dissonance caused by evolution. I dislike any religious fanaticism whether it’s a crusade, jihad, IRA or free software. Any religious motivated fanaticism is harmful and needs to be fought, even if it is free software. Yes one can grow a thick skin to handle the fanboys, but that just shouldn’t be needed. Being compared to Hitler hurts no matter how thick your skin is. And if a GNOME developer stops work because of KDE fanboys it’s not GNOME who lost a developer, it’s free software who lost a developer. It’s one of us. We are also GNOME!

Final remark: please don’t come and tell me that I’m the same by criticizing Mir. It’s not the same. Criticizing decisions and having discussions is important, but of course critic has to be constructive. I have never attacked any of the Mir developers or have attacked the software in any way. I criticized the decision and the reasoning and pointed out the problems it causes for us, but I have in no way attacked Canonical, Ubuntu or Mir.

[1] Yes there are free software developers who are called a “benevolent” dictator. I disagree. There is no such thing as a benevolent dictator. Every dictator is bad and one shouldn’t define dictatorship down by calling someone a benevolent dictator.

[2] Yes all of that happened to me. Someone even compared me to one of the worst mass-murderers in human history because I do free software and have an own opinion.

Posted on

Starting a full KDE Plasma session in Wayland

This week there will be the release of KDE SC 4.11 Beta 1 and this will come with an interesting new feature: an experimental Wayland backend inside KWin. This backend does not allow to manage Wayland clients, but uses another Wayland compositor as the rendering target. Instead of rendering to an X window, KWin renders to a Wayland surface. From an architecture point of view this means that there is a Wayland system compositor and KWin is running as a Wayland session compositor (although KWin is not yet a Wayland compositor).

Disclaimer: this is a highly experimental feature and not intended for productive usage. Please do not report any bug reports in the bug tracker. If you find an issue please open your editor, hack and submit a review request.

Now I expect that you are also excited about Wayland and that you want to run your KDE Plasma session on top of Wayland instead of X, right? So here are the instructions: First of all you need to change the “Tearing Prevention (VSync)” in KWin’s Advanced desktop effects settings to “Full scene repaints”. This is needed because KWin does not yet support the buffer-age extension needed to properly repaint in Wayland. Note: when using X11 you probably don’t want to use this option, it wastes quite some power.

The KDE Plasma session startup is controlled by a script called “startkde”. In order to start the KDE Plasma session with Wayland we also need this script, but need to have a few environment variables set to tell KWin that it should use Wayland. So best copy this script and call it” startkde-wayland”. Edit this file and add the following exports after the shebang:

export DISPLAY=:99
export WAYLAND_DISPLAY=wayland-system-0
export KWIN_OPENGL_INTERFACE=egl_wayland

Now all we need is another small shell script to start Wayland, Xvfb and the modified startkde script. Let’s call it kwayland:

#!/bin/sh
weston-launch -- --socket=wayland-system-0 &
Xvfb -screen 0 1366x768x24 :99 &
startkde-wayland &

Please change the screen resolution to the one used by your screen. KWin is not yet able to update the resolution of the X server to what Weston uses. This also means that you cannot change the resolution or add multiple screens (as I said: it’s an experimental feature).

Now log out of your running KDE session, switch to a tty and stop the still running X server. With X out of the way you can start the kwayland script. You should see Weston starting and shortly afterwards KWin should take over. If everything is configured correctly you should see the normal splash screen (seems like my system is not configured correctly).

Once the system is fully started you can just use it. If everything works fine, you should not even notice any difference, though there are still limitations, like only the three mouse buttons of my touchpad are supported 😉 I would post a screenshot but it’s fairly uninteresting as one cannot see a difference.

This blog post was written in a KDE Plasma session running in Wayland.

Posted on

New KWin Scripting Feature in 4.11

Today is the feature freeze for 4.11 which is a good point in time to blog about the new functionality in KWin Scripting in the upcoming 4.11 release.

Configuration Interfaces

Since 4.11 our scripted components support configuration interfaces. Already in previous releases it was possible to define a KConfigXT file which can be read in the script. In 4.11 it’s now possible to have a ui-file bound to the KConfigXT file and KWin generates a config module from these two files. All that is needed is to modify the metadata.desktop file so that KWin knows that this script comes with a config interface:

X-KDE-PluginInfo-Name=kwin4_effect_foo
X-KDE-PluginKeyword=kwin4_effect_foo
X-KDE-Library=kcm_kwin4_genericscripted
X-KDE-ParentComponents=kwin4_effect_foo

The X-KDE-Library needs to be set to “kcm_kwin4_effect_genericscripted” and X-KDE-ParentComponents and X-KDE-PluginKeyword need to have the same value as X-KDE-PluginInfo-Name. The KConfigXT file is expected in contents/config/main.xml and the ui-file is expected in contents/ui/config.ui.

If these few steps are followed the effect respectively the script KCM shows a configuration button for the component.

Set and Cancel Animations

The animation API got a small addition: each animation has an id which can be canceled later on with the id. Cancel stops the animation immediately, it is not reverting the animation. So if one wants to revert the animation one still needs to schedule an additional animation.

Canceling an animation for itself is not that interesting, but in combination with another new feature it becomes very important: set animations. The new set animations are just like a normal animation but they stay in the final animation position until the animation gets canceled. A normal animation just performs the state changes, e.g. fading in or out a window. But it’s not possible to fade out a window and keep it faded out. When the animation ended the window will be visible again. Now the new set animation will keep the window faded out. This is used for example in the JavaScript version of the translucency effect to animate the moving of a window:

moveResize: {
    start: function (window) {
        window.translucencyMoveResizeAnimations = set({
            window: window,
            duration: translucencyEffect.settings.duration,
            animations: [{
                type: Effect.Opacity,
                to: translucencyEffect.settings.moveresize / 100.0
            }]
        });
    },
    finish: function (window) {
        if (window.translucencyMoveResizeAnimations !== undefined) {
            // start revert animation
            animate({
                window: window,
                duration: translucencyEffect.settings.duration,
                animations: [{
                    type: Effect.Opacity,
                    from: translucencyEffect.settings.moveresize / 100.0
                }]
            });
            // and cancel previous animation
            cancel(window.translucencyMoveResizeAnimations);
            window.translucencyMoveResizeAnimations = undefined;
        }
    }
}

This code snippet shows how to use the set animation and where one can best store the returned id: just use dynamic properties on the window. Also it shows how the animation can be reverted by specifying an animation in the opposite direction.

When using the set functionality one needs to be aware of one aspect of the behavior which can be considered as a disadvantage: the window will considered to be rendered with this animation until it gets canceled. Even if the window gets closed, minimized, activity changed or virtual desktop changes. The window will be there. So one needs to connect to events which could make windows go away and cancel the animations. Also when a window becomes visible again one should start the set animation again. There is a very easy test to see whether a window is currently visible: a new property called visible which is defined on the EffectWindow. It’s true if the window is currently not minimized, on the current desktop and on the current activity.

New Animation Types

4.11 also allows to animate in two new ways. There is Effect.DecorationOpacity which allows to just animate the opacity of the window decoration without changing the opacity of the whole window. Like before using Effect.Opacity animates both window content and window decoration. Obviously this only works with server side decorations.

The other new animation type is Effect.CrossFadePrevious which is a rather interesting new animation type for improving animations when the size of the window changes. When used KWin will keep the previous window texture and render it on top of the current window texture. This allows to cross fade from the previous window size to the new window size. If one wants to see it in action: the maximize effect is using it. This feature is currently only available in the OpenGL compositors.

New QML Components

The KWin QML Scripting API got extended by one new component: DesktopThumbnailItem. This component can render a preview of a virtual desktop:

KWin.DesktopThumbnailItem {
    id: thumbnailItem
    clip: true
    desktop: model.desktop
    anchors {
        fill: parent
    }
}

This component is used for example in one of the new desktop switchers.

Client Models

4.11 comes with a set of new models which can be instantiated in QML.

ClientFilterModel {
    id: filterModel
    clientModel: ClientModelByScreen {
        exclusions: ClientModel.DockWindowsExclusion
    }
    filter: screens.filter
}

These models are meant to be the base for functionality like Desktop Grid or Present Windows. 4.11 includes a SimpleClientModel, ClientModelByScreen and ClientModelByScreenAndDesktop. More models can easily be added, just let me know what you need. Also there is the ClientFilterModel which is a helper model to perform searches like known from the Present Windows effect.

Although these models are shipped in 4.11 KWin does not yet use them. They are meant to replace Present Windows and Desktop Grid in future, but this has to wait for QtQuick 2.