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.
For my own experience, turn kwin effect off will make my battery life longer for 30min ~ 1 hour.
I just done a very little experiment with powertop. I think you can also try it on your laptop to check it.
18.9W (2.6hours) vs 14.7W (3.2 hours)
with effect on, fglrx will be the top one wake up kernel, while the effect off fglrx will disappear from the top.
I think we can test it with more experiment :), to see whether this is only ATI/fglrx case or a common case.
I was talking about KDE Plasma 4.8 and you? 😉
And yes fglrx is an own beast and I can only recommend to not use it. With fglrx you don’t get the new code which is available since 4.7
Yeah, I know fglrx is blacklisted from kwin’s OpenGL2 code. So I don’t know what’s for the open source driver. But the only reason I use fglrx is for power saving…
And I can totally understand what you want to explain, but anyway numbers can convince more people, right? powertop can give the quick result of idle state in less than 5 minutes.
I got similar result with the nvidia proprietary driver, lastest stable version, on trunk from today.
With compositing on battery life drops of more or less 50 minutes. Which is *a lot*.
That is for KWin 4.8. As has been said here before, in 4.7 and below, disabled effects participate in the rendering, and waste CPU cycles, sometimes greatly. 4.8 fixes that once and for all.
OTOH, if you have an old NVIDIA chip (pre-G80) remember this tweak still applies…
Option “RegistryDwords” “PowerMizerEnable=0x1; PerfLevelSrc=0x3333; PowerMizerLevel=0x3; PowerMizerDefault=0x1;PowerMizerDefaultAC=0x1”
If you have a new NVIDIA chip, you can still reduce power consumptions to acceptable levels disabling Blur and switching your scaling method from “Precise” (Lanczos filtering) to “Smooth” (bilinear filtering).
I already said that I tested on kde trunk from today.
I would believe what you are writing if it were backed by some numbers. Other than that i am not sure, i guess it’s true if we deal with some Intel crap that does most of the rendering on the CPU but there’s still more operations to be performed by cpu when compositing is on? And what you are talking about is just a short spike in power usage.
Let’s turn it around: do you have numbers to contradict my experience?
Thats what I mean, I’d ask everyone to test it or why not put some code for one release that would test the power usage, something like a “survey” for users to help test the power usage etc. You probably are right but is it the same case everywhere? Are there some corner cases that condradict what you experience?
there are things you cannot test, like the impact of changing the user’s workflow. And as said: the user is still able to manually suspend compositing, though we recommend not to do so.
Wow, wow, hold on there.
Compositing makes playing (and SPECIALLY developing!) games a complete chore because it lowers FPS dramatically, even in games with low video usage. I can show you code proving it, that makes a blinking effect and it’s completely invisible if compositing is enabled, the effect can only be seen if it’s disabled, even with a card that doesn’t struggle with Kwin compositing at all!
Are we turning Gnome now with the “sane defaults” thing? Because you’d better start a kwin2D fork then. Also, my system is wired to AC, I am not using some tablet or whatever, I can take the power usage, but not the lowered video performance. How am I expected to code FOSS games if I can’t see the effects I am coding properly?
And, I don’t even lock my screen, I just turn it off whenever I am not using it. That saves more power than this…decision.
please see: http://blog.martin-graesslin.com/blog/2011/09/developer-and-user-interaction/ why I won’t accept the GNOME argument and will not comment on what you wrote.
I am comparing it to Gnome3 where compositing cannot be disabled, like you are trying to do here. I find that a pretty valid comparison right now, with passive-aggressive blog post or without.
This affects my work area pretty negatively, and it came out of nowhere. You should at least acknowledge one vote against that feature. The FPS drop is still a concern no matter what you say. I shouldn’t need to upgrade the video card that moves my content perfectly just because someone decided to add an extra layer of video processing on top, that cannot be disabled.
You still can turn off compositing manually. It’s just that an automation has been removed.
Yeah, I noticed in the replies below. I apologize.
Besides, if you search phoronix then there is an article about compositing managers and their impact on games etc. to cut the story short, kwin is basically the best.
the test was actually flawd – that’s just for th record
Phoronix can be leaved out of the tests. Their test methods and writing styles has been every time analyzed and thrown over the list of valid argument points in Slashdot comments when Phoronix has tried to advertise their site.
Why you won’t accept it? Just because the guy wrote truth? We, KDE users doesn’t want gnome, so you would better understand this. We don’t like gnome, the way it’s evolving or its devs dictating users what’s right and what’s wrong. I recommend you to change your behavior.
This is a warning: you have been trolling in my last blog posts and you try it here again. I won’t accept any trolling in my blog. If a see any more troll posts by you, you will be blocked.
I have a few concerns concerning this new “enforcing compositing” decision.
Noadays a lot of people still struggle to make compositing work, because of experimental/broken opensource drivers for example, and when compositing does work, the performance is sluggish on the desktop and/or also in the 3D apps and again, because of driver issues (proprietary ones too)…
I have a desktop computer with an HD 4670. Kwin effects run fast and smooth, but then I get execrable performance on the games and other 3D apps. Even the “smooth scrolling” from Chromium gets very sluggish when Compositing is enabled. So I simply can’t afford to let effects on even if they run fine.
I know KDE/Kwin is not the first to blame but rather X and fglrx, but still I don’t think enforcing compositing is the way to go, especially to care about unborn projects like Wayland…
KWin will not enforce compositing, if compositing is turned off, it stays off. It only enforces if compositing is on.
Then you should clarify that in the post, the words you choose make it sound like compositing will be forced starting in 4.8.
Just to make sure I understand you right::
It will still be possible to run KWin without compositing – but if you start it with compositing on, you won’t be able to turn compositing off without restarting KWin. Correct?
No, it is still possible to run KWin without compositing and it is still possible to turn compositing off when running with compositing unless compositing has been on when the screen is locked. As soon as the screen unlocks it possible again to turn compositing off.
Just to clarify: the ONLY thing that is happening is that the KDE power management interface will no longer have the “disable compositing” checkbox when you are configuring your power profiles. (you also cannot turn off compositing when the screen is locked, but ideally you can’t do anything when the screen is locked anyway) All the other places where you can enable or disable compositing will remain the same.
This is purely about power management and only power management. Of course that will all change with wayland, but that is another story entirely.
At least that is my impression, please correct me if I am wrong.
everything correct
Okay, thanks a lot for your reply, now I’m reassured 🙂
I really hope some day the current Linux graphical stack mess will finally be fixed and optimized so Compositing can work natively without bugs and impact on other apps.
I still remember the early Compiz years, when everyone was stating that theorically using a Composited environment would reduce the CPU overhead, sadly due to all the drivers (opens or not) and X issues, it has never, and is still not true.
It saddens me to see how better performs Windows 7 with Compositing enabled, with almost no impact in gaming and video, not needing ugly hacks like unredirection to avoid performance issues…
I really wish someday Compositing would be useable everytime for a daily and for every kind of computer use.
Anyways thanks a lot again Martin for all the efforts you have put in Kwin and for all your blog posts, ones of the few that the simple user I am can understand ^^
This day when compositing performs better gets near with Wayland 🙂
I know this is fairly off-topic, and not really your area, but what about widget animations? I don’t mean plasma widgets, I mean widgets in windows (like tabs, buttons, menus, etc). Would turning off animations for those off help any?
yes of course
Should this be added to powerdevil then? I am not sure oxygen even supports this, though (I mean one switch to turn off all animations, of course you can turn them off individually).
we would first to have to implement support for that in all the places where it makes sense, then we can add it to powerdevil
Yes, of course that would be needed. I seem to recall someone saying that oxygen doesn’t support this currently, which is also breaking system settings -> application appearance -> style -> fine tuning -> graphical effects, although that may have changed (or I am remembering incorrectly to begin with).
yes there is a unique switch to turn all animations off in oxygen, and in fact, I could connect it to any signal you point me too.
In fact reading the blog I was asking myself the same question (about widget animations vs power-save)
Actually, dbus signal would be better, cause this way I could also connect oxygen-gtk to it.
I remember a Mythbusters episode where a car manufacturer said that its car model burned less fuel with air conditioning on than with windows open (more turbulence and drag). Turns out it didn’t work in real-life situations, possibly only in wind tunnels. I see where you’re coming from, but I have a gnawing feeling it’s painting the best-case scenario, or cherry-picking hardware.
It’s a sad but hard truth that some video drivers aren’t as optimized as others. Should we interpret this as a passive-aggressive way of telling them to shape up? Moreover the impact of the one-time effort of kwin letting go of resources and telling X to take the reins again decreases as battery life grows. Some ultraportables claim upward of 9h life with minimal use.
If you concede that it may not work out well for all drivers, why remove the option to opt out? I realize the importance of sane defaults, but I’m still not convinced about removing options. It’s also a pet peeve of a large portion of the userbase, and (while irrelevant and eventually probably beneficial) the talk of frameworks going binary-incompatible 5.0 is already tearing up some old wounds. A hidden kwinrc option would help in a way (let advanced users opt out) and harm in another (enforcing the view that configuring *nix OSes is hard and unintuitive).
As for the 17ms throttling, is this hardcoded or calculated based on the refresh rate on the screen? Mine is a 120hz TN LCD, and I’d very much like my games’ windows (Wine or native) to update at 120fps whenever they can. Not all LCDs are 58-60hz, not to mention CRTs.
If powertop and/or watt meter reports show 4.8 code as drawing more power, will that prove this change as unwarranted? I can already imagine the Phoronix wattage benchmarks this will spawn, and people *do* read those.
It’s always possible to just use the Alt+Shift+F12 shortcut to be smarter than the system 😉
Concerning refresh rate: yes of course it’s using the system’s refresh rate and will use 120 Hz if that’s what your system provides.
Just to make that clear: you aren’t talking about the nice feature in Power Devil’s profiles?
It is not alone about working on battery – this option is also nice working on AC – e.g. I have a profile for watching movies or for downloading, where I don’t want to have effects enabled.
> It’s always possible to just use the Alt+Shift+F12 shortcut to be smarter than the system 😉
The thing with shortcuts is useful for power users who know them – but that is not the case for most users.
for things like movies you can configure a window specific role to make the window block compositing. That’s even better than what the profile provided.
That is SUCH an awesome tip… Thanks, made my life better!
“The thing with shortcuts is useful for power users who know them – but that is not the case for most users.”
To be fair, the same is probably true for custom power management profiles… 😉
Press that Edit button and include a “NOTE: It is still possible to manually disable compositing through the keyboard shortcut” to avoid even more unnecessary comments 😉
And it’s possible to reenable the “Unredirect fullscreen apps” automation, too.
Yes but when the screen is locked with compositing enabled, unredirection is not possible.
“[…] to avoid even more unnecessary comments”
I’d be more concerned about those readers who *don’t* comment, but rather just go off with the wrong impression and then start spreading it as FUD elsewhere…
One thing I noticed when kwin is running with composite is that it seems to generate lots of wakeup events in powertop, about 50-80 events/s even in idle, another 150+ events/s from hrtimer_wakeup and tasklet(softirq), so when I have composite enabled I get 200+ more events/s. I know it does not necessarily mean it costs a lot more power, but I am wondering if there are some possibilities to improve it. I am using nvidia binary driver 280.13, the number of wakeup events does not drop even when the driver is running in the lowest performance level
60 wakeup/s are to be expected with compositing on. You might checks whether the track mouse effect is enabled – this one is also triggering wakeups.
Is it possible to eschew wake-ups when nothing is going on? Say I have this blog open and am reading it, but not scrolling or moving the mouse. It seems to me that there ought to be a way to have KWin just sleep indefinitely until something happens.
Thanks for the tip Martin, I disabled all the effects I am not using everyday, now I get much fewer wakeups, even kwin itself only triggers 2 wakeups/s with compositing. Somehow I still get 2-4 fewer watts without compositing (measured when the machine is idle, no mouse/keyboard action), not sure about the exact reason
It would be great if someone collected some real world data to back up these theories.
martin,
have you made any tests about the power consumption on your configuration(s)? can you publish them?
I do not think that there is any use in publishing the results from just one hardware. The changes are motivated by the knowledge about the architecture
“Overall I hope you see that turning compositing off will be worse for the battery than keeping it on.”
No, I just see a bunch of assumptions backed by no hard data.
I know anecdotal evidence ain’t the best, but I can tell you: without compositing, I’m 100% sure my system eats more memory. My Intel/NVidia system gets completely bogged and to 90% CPU on the most basic actions (yes, resizing, but also switching windows) if I run it without compositing for a few hours while with effects on – completely smooth and no CPU usage…
Thank you for another great blogpost. You show great skill in explaining highly technical stuff in a way that even I (a non-coder) can understand it. Or make me at least think that I understood it. Keep em comin.
I share concerns in this thread. I have “Disable Desktop Effects” in powersaving profile (which actually disables compositing, for all I can tell). And it does reduce power consumption as reported by powertop, and appears to make laptop run more on battery. If you disable this feature based on your belief how KWin works, and not on measurement that show this is OK on common hardware, you are ignoring well-known truth that all performance-related work must be guided by a profiler.
you probably share experience with 4.7, try again with 4.8 – we changed a lot!
I surely trust you when you say that you’ve changed a lot. But, you are taking away a feature, without actually proving that this feature no longer has noticable effect on battery consumption. Things like performance, memory usage and battery consumption are not the things you can determine in the abstract, you need to measure them, and your resistance to try is suspicious 😉
we are not taking away a feauture. You still can manually disable compositing. We only remove a checkbox whixh is not checked by default, worked unreliable and should never had been introduced in the first place.
Automatic disabling compositing when I pull a plug surely *is* a feature. After all, my laptop can sense just fine that it’s undocked, adjust screen brightness, switch to wifi network and so on, and does that perfectly reliably. Seems like disabling compositing at the same time is pretty in line with other automatic changes?
“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.”
Couldn’t you just set the animation speed to “Instant”?
If it were that simple, sure 🙂
I find it really great what you do and that you provide such an awesome dektop environment for people that don’t want to use the alternatives for various reasons.
Just a quick question: I have a netbook where compositing is currently being disabled, when it is on battery. Whether it saves battery or not is not the biggest problem for me, but the even more pressing issue is, that the CPU gets dialed down. Without the effects, the window manipulation is pretty OK, but when effects are turned on and the netbook is on battery, all the actions like moving and resizing windows is comparatively slow. I assume that is because some of the rendering happens in the CPU and not the GPU.
Will that be better with the new code and the new compositing strategy or do I just have a crappy netbook? 😉
Thank you again for the great work!
Window moving should always be better for battery with compositing enabled. If it isn’t for you, something is broken, but it’s unfortunately always possible that what is best for most is worse for some.
Ehm, most linux games and wine NEED compositing disabled if you want to get speed from your videocard. Forcing compositing always ON means losing gamers.
But that is not affected, the opposite is true. We even provide an API to the games so that they can disable compositing