Window Switcher in QML

Yesterday I merged in the new Window Switcher Layouts implemented in QML. As before there are five available layouts but now it is easy to add further layouts. So I am waiting to see some new layouts. If a well-done layout is sent to me, I can include it in our default shipping till the artwork freeze. So use the chance to get your window switcher into our default offerings!

Thanks to the possibilities provided by QML we have now a layout configuration which shows directly a preview and not just a name as before:

For the old implementation I tried to provide a preview at least for the selected layout and it was never working properly and I removed it again in a later release. Doing the same in QML took just a few hours and I am still a QML beginner.

KWin meets QML

Two years ago I started to re-implement the Window Switching capabilities of the KDE Plasma workspaces (also known as Alt+Tab or TabBox). The old implementation was based on a QWidget with custom painting which of course had some drawbacks. The new TabBox evolved into a framework around Qt’s Model-View concept to design your own window switcher.

Before I started to work on that area I did evaluate the existing Window Switching capabilities of the various desktop shells (both free software and proprietary solutions) and I noticed that all of them have drawbacks. None is the solution where I would say: that’s the perfect switcher.

The main issue is that depending on the user’s habits different work flows are required. A switcher optimized for users with few open windows fails for users with many open windows and vice versa. Especially thumbnails become useless for many open windows.

So I realized that we need something flexible enough to give users the possibility to use different layouts or to even define their own layout. This ended in a framework for window switching. The layout is described with an XML file and rendered through custom painting code in a Qt delegate.

When I implemented this framework I wanted to add a GUI to easily configure own layout. Unfortunately I never got around to implement this UI and I think there has never been any other layout except the default shipped once. It is a rather unknown feature and I’m quite unhappy that this great functionality never got implemented.

In the mean time the trolls did a great job to make UI development easier: QML. This makes it possible to do what I wanted to have for window switching: easy to design and exchangeable layouts. So this weekend I implemented the default (informative) layout in QML and plan to completely replace the existing View and Delegate code in 4.8. And this gives us the possibility to let users write their own layouts and to share and exchange them.

But this is only the beginning of usage of QML in KWin. I have many more ideas by making window thumbnails available to QML UIs in a limited way. This will allow us to even integrate the BoxSwitch effect into the normal window switching framework and replace the Window Strip in Plasma Active.

So great UI times ahead in KWin.

KWin on Pandaboard

Thanks to Canonical and Linaro I received a Pandaboard some time ago. Finally I succeeded in building KDE on this device (I have never seen crashing compilers before). And I am proud to announce that kwin_gles (master) runs out of the box without any adjustments on this board.

As today is also KDE’s birthday I present the KDE Crew: All my devices running KWin on one photo (the next to be konquered device was involved by doing the photo).
KDE Decice Crew

The screen on the left is connected to the pandaboard between the right screen and the laptop. As you can see it is running Unity-2D with KWin. I tried really hard to show a real Plasma on the Pandaboard, but Unity did not liked to be killed 😉

We see KDE is prepared for the devices coming in the next 15 years. HAPPY BIRTHDAY!

Results from poll about future of XScreensavers in KDE Plasma

Today ended the poll on forums.kde.org about the future of X Screen saver support in the KDE Plasma Workspaces. I want to thank everybody who participated in the poll. The poll and the thread clearly help us to see what the users need and want and what we need to provide.

Here are the results:

  • 153 (53.5 %): I don’t use screen savers, it doesn’t affect me
  • 92 (32.2 %): Finally new screen savers, thanks a lot
  • 22 (7.7 %): I would miss them but could live without them
  • 4 (1.4 %): I would complain
  • 2 (0.7 %): I would switch to another Desktop Environment
  • 13 (4.5 %): I don’t care

Of course the poll does not reflect the diversity of our users. We are not able to reach the Pennys out there who do not even know that they use the KDE Plasma Workspaces. But I am personally convinced that the Pennys do not use screen savers as we do not enable or even install screen savers by default and make it non trivial to configure them.

We always try to develop the software so that most users are suited well. The poll result shows that only a minority really wants the old screen savers, but that one third of our community is eager to get new and modern screen savers. But even more important is that more than half of our user base will benefit from the work on the new screen locker directly.

This confirms the plan we have to improve the screen locker for 4.8 and that keeping the screen savers as a fallback is an acceptable solution for 4.8. Given the results I will also look into getting the new screen savers ready for 4.8 and not only for 4.9.

Again thanks to everybody who participated in the poll to make the KDE workspaces better.

New Screen Locker

Some might have already read about it: we are currently working on a new screen locker. The old implementation is mostly a hack around X. There is the lock window which tries really hard to be the top most window. Obviously this does not often work, especially as the whole framework is way older than Compositing.

Too often I have come back to my system or resumed from suspend and seeing my windows shine through. Or seeing some notifications on top of the screen locker. We decided to change that and solve it once and for all in a proper way by putting security first and moving the screen locker into the Compositor.

The Compositor controls the rendering, so it can ensure that nothing gets above the screen locker. When we have the compositor being responsible for the screen locking we also get nice fading from and back to the desktop for free.

My initial idea was to just move the screen locker to KWin but not changing the unlock dialog. But now I started to play around with QML and need your help:

QML unlock dialog

You can see that I am really no expert in doing user interfaces. So if you have some QML experience or just want to help defining a very important area of Plasma, please get in contact with us. I will do all the JavaScript and coding, so that only the QML is needed.

The new way unfortunately conflicts with the existing screen savers. They are almost 20 years old and we have problems to keep support for them. At the moment we decided that if you have a screen saver configured the old implementation will be used with all the security issues. But we are not yet sure what to do in 4.9. As we use QML it would be possible to write new screensavers in QML. This would allow us to keep the improved security and to only need one code path. But we are unsure how our users will react on removing the X Screen Savers. To find that out we set up a poll on forum.kde.org and I would like to ask you to participate. This will help us to define our next steps.

The new screen locker will also be used by the first version of Plasma Active, which will be released in a few days. There we use the same architecture but ship a different QML file which does the unlocking without needing a password (we only want to protect for unwanted touch events). This shows that it is possible to exchange the QML files for custom screen savers.

Moving the screen locker into KWin has also more security advantages in addition to the protected screen content. Of course KWin is very crash resistant. So if the screen locker crashes KWin will just restart and lock the screen again. Even if KWin would completely fail it is more secure than before as without a window manager you can hardly do anything with the system. Also we have finally a real solution for the most often reported KWin crash of all time: the Intel driver crashes KWin when the screen saver is used due to unredirecting the fullscreen saver window. With the locker being a KWin effect it is impossible to trigger this driver crash.

Some users might wonder what that means if they don’t use KWin. Well as the screen locker has been moved to KWin you can no longer lock the screen if not using KWin (the same way you could not lock the screen if not using KRunner before). If you want to lock your screen in Plasma 4.8 but don’t want to use KWin you should get in contact with your Window Manager vendor. Sam from Compiz wanted to add support for it in Compiz. For anything else I don’t know. So why did we do it: we think that the security of most of our users is more important than the need of some users to use a different window manager. Also we had added many integration features to Plasma in the past and if you were not using KWin you lost these features. With the screen locker it is now exactly the same: you lose the integration feature when not using KWin. I also want to remember everybody who wants to complain in the comment section that the KDE Plasma Workspaces are an integrated product consisting of the Plasma Desktop Shell, KWin, KDM, Systemsettings and a few other applications. We develop this as one product, so if you want to remove a part, well that’s your decision, but we have to compromise and we clearly see that other vendors are integrating their window manager even further into the desktop shell than we do.

Correcting misconceptions about Power Saving and Desktop Effects

Apparently the English I write is too difficult to understand for the average reader – including so-called free software journalists – (which surprises me as I am a non-native speaker), so I have to be more clear about what I wrote yesterday before more FUD is being spread.

What is going to be removed?

One checkbox in the power management settings to automatically disable compositing when battery runs low.

Does that mean I have to use Compositing?

No! You still can disable Compositings in Systemsettings, use the Alt+Shift+F12 shortcut or use a window specific rule to block compositing if e.g. you are using VLC or Wine. You can even write a very short script using our D-Bus interface to disable compositing when the battery runs low. You see even the exact same functionality is still there, it’s just a removed checkbox.

What about enforcing compositing you wrote about?

That is only the case if the screen is locked with the new implementation. As soon as you unlock you can disable compositing again and of course if compositing is disabled it stays disabled when the screen gets locked.

I hope that clarifies everything. Just remember: we always do what is in the interest of our users. If you want to go OMG THEY ARE EVIL it is more likely that you misunderstood something than that we are evil 😉

I would appreciate to see updates to the blog posts which spread the FUD that we enforce compositing. This is really bad!

Power Saving and Desktop Effects

For a long time KDE Plasma offered to turn off Desktop Effects when battery runs low. In the past we changed the default to keep compositing on and now in 4.8 we remove the option completely.

We all care about power saving and so it is important to understand why keeping compositing on will most likely save more power than turning it off. (As with all hardware and driver dependent functionality we can only offer what is best for the majority of users, it is possible that with specific hardware turning compositing off would in fact save more power.)

So let’s have a look at what happens when you turn off compositing:

Turning Compositing Off

Window decorations

Our default window decorations uses a shadow build into the decoration itself. When you turn off compositing the shadow has to be removed. Given the way the shadow is implemented, this means that each window has to be resized and moved back to its position. Furthermore all window decorations have to be completely repainted.

Plasma

Everything that is painted in the desktop shell is a pixmap rendered from SVG. Plasma uses a cache for the recently generated pixmaps. The themes itself come in three forms: one for no-compositing, one for compositing and one for compositing with blur. When turning off compositing the theme has to switch from one of the two composited to the non composited. This means we need to access the hard disk to load the SVG. Then we have to render the SVG in the correct size to a pixmap and access the hard disk again to save the pixmap in the cache. This has to be done for each Plasma styled window: the panel, KRunner, the tooltips, Alt+Tab, Kickoff. Also in later states during using it is likely that the same cycle happens again: e.g. the size changes of KRunner. With compositing it’s most likely in the cache, with non-compositing it isn’t.

KWin itself

When turning off compositing KWin has to be quite busy. All the effects need to be turned down, lot’s of resources have to be released. The OpenGL context needs to be destroyed. The overlay window has to be removed, quite some properties need to be removed from the root window (support for blur, taskbar thumbnails, etc.), the manager selection has to be released. So overall quite some roundtrips to the X Server till everything is teared down correctly.

X Server

With compositing disabled the X Server becomes responsible for rendering the screen again. It no longer has to redirect the windows into offscreen pixmaps and notice KWin through the damage extension about changes. It has to update the screen and perform the clipping of the content. Pretty much the same what KWin did before.

How the Desktop Effects work

As we see overall turning compositing off is a rather heavy operation. It involves many applications, many context switches and lot’s of I/O. All the things you don’t want to do when running low on battery. But later on having compositing turned off must really bring power saving, right? To answer that we have to look on how KWin performs the rendering.

How KWin renders

KWin is notified by the X Server about an update in a window (damage) and triggers the next repaint. The repaint starts with asking all loaded effects whether they are active. In a normal situation only the blur effect will be active, all other effects won’t participate in the rendering. Each participating effect is asked to perform its transformations and additional rendering. In the normal case the blur effect notices that the window does not have to be blurred and does exactly nothing.

The windows are rendered from top to bottom. That is if we have an opaque window on top, the one below won’t be rendered. Only if it is translucent it will be rendered from bottom to top (that is all windows). So in the normal case (area of a window updated) only one window will be updated. The rendering itself is just a very simple 2D texture rendering. Yes it’s 2D, not 3D.

After the window is rendered KWin goes back to sleep to wait for the next damage event, it does not perform constant rendering.

But it’s using OpenGL, that’s expensive on the GPU!

Well think about it. Someone has to bring your updated windows on the screen. This someone is the graphics card. You need it anyway, no matter whether it is KWin or the X Server. KWin uses OpenGL to do the rendering, which means it’s hardware accelerated. I do hope that the X Server uses hardware acceleration to do it’s rendering 😉 In the most modern architectures (like Gallium3D) 2D is just a special case of 3D. I honestly don’t see how using X instead of KWin to perform the 2D rendering should save any power.

But can’t you at least deactivate the effects?

As explained above only active effects will participate in the rendering. So if you don’t use the cube effect, it won’t be used and cannot consume power. If on the other hand you use the effect than it is adding usability features. Imagine a user who switches windows using the Present Windows effect. Of course using this effect actively will affect the battery life. But what is worse? Using the effect once very shortly or searching a minute for the window in the taskbar? What will affect the battery life more? The minute searching (one minute less battery) or the animation?

But at least Blur should be disabled!

It is true that Blur is the most expensive effect we have depending on the hardware you have. That’s why we are optimizing the effect (thanks to Philipp for all the work on it). First of all: if the rendering of the window does not intercept any blurred area, the blur effect won’t do anything. If the rendering intercepts a blurred area the part has to be updated. Thanks to some optimization we only have to update this part and we cache the blurred background. So blurring is no longer that expensive as it was. Now we could nevertheless turn blur off, but that would require to generate new pixmaps (see above) and I doubt that this is better than doing some blur operations.

What about the animations?

Animations are probably the only thing where it might make sense to deactivate when running low on battery. Animations trigger repaints so they are not cheap. But to change that quite some work is required and I am not sure if it is worth it. So if you can do an evaluation on how expensive the fade effect is for the battery life we might consider to add a way to disable the animations.

Where Compositing helps to actively save power

There are operations where compositing is much better than good old X. For example when moving a window only some texture rendering need to be performed. With X the areas where the moved window used to be needs to be repainted. The same is of course true for resizing. Another advantage is that KWin renders with a well defined frame rate. No matter how often a window tries to render, KWin will throttle it. So a window generating damage events each millisecond will be rendered only each 17 msec. And yes there are applications out there trying to render as often as you can. Preferable some old icons in the systray or non-standard toolkits.

Where we enforce Compositing

KWin in 4.8 is the first version which will temporarily enforce compositing. This is currently related to the new screen locker. The new screen locker is implemented in the compositor to ensure that the screen is always blanked (something the old one could not guarantee). When we use the new locker KWin ensures that compositing cannot be turned off! So imagine we would allow turning compositing off when running low on battery.

First scenario: active usage. Compositing is turned off and later on the system goes to suspend and locks the screen with the old insecure implementation. I hope you all see that security is important.

Second scenario: screen locked when battery is running low. The power management functionality will try to turn off compositing, but it will fail and the power management will never notice about it. There is in fact no way how the power management could notice that and it would have to try again and again to turn off compositing. That sounds clearly wrong to me.

But 4.8 will hopefully have another situation where we need compositing: Wayland. When we run a Wayland server we will not allow to turn off compositing, because you would lose your Wayland windows. Currently the code is not yet merged and most likely the distros won’t have packages available anyway but it is something we have to plan for. With Wayland we need compositing, so turning it off doesn’t make sense.

Overall I hope you see that turning compositing off will be worse for the battery than keeping it on. We are concerned about helping the environment and giving our users the best of the limited resources. That’s why we removed the feature: to help you and not use wrong settings just because you assume that 3D is worse than 2D.