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.
