KWin Now Supports Suspended Compositing

[mrugiero]

Things are not nearly as clear-cut as you make them. By working with each window independently, the compositor can reduce CPU usage when moving windows around. Without a compositor, you need to repaint each window as it is gradually uncovered. With a compositor, you can simply blit the persisted window contents to the backbuffer.



I have tried this but it tiling just didn't appeal to me. The window layout tended to be suboptimal until I corrected it manually. If I have to move windows manually, I might as well do away with the tiling manager completely.

That's a good point, I didn't thought about that. However, I'm not trying to show how "OMG! Compositing is EVIL!", my post is primarily an answer to the guy who said something like "Why anyone would not want compositing". And my point to that respect, is still correct. There are several reasons, the main reason is about not being commanded to use it, is freedom. If compositing works awful for you because your GPU's driver is shitty, the fact it is not fault of the compositor's programmers does not change the fact that it does not work OK.
If I have a computer which works OK with compositing, I usually use it, in fact, in the machine I'm right now I use XFCE with compositing enabled. The way I use it, it is just for the eye-candy. Some people showed me practical reasons to use it here. The problem is when someone suppose that everyone should use the things they use.

[DoDoENT]

The problem is when someone suppose that everyone should use the things they use.

Exactly! I'm using composition now because it works with recent drivers. When it didn't work, I didn't use it. But it's easier for me to move windows from one desktop to another in desktop grid or to pick a window from a expose effect. On the other hand, some people prefer just using one desktop, some people use one window per desktop, some people use one terminal per desktop (1337 ), but that is personal preference. And I always liked KDE because it has always been configurable and it has always given you choice whether you want to use desktop effects or not, whether or not you want to use single or double click to open files etc. GNOME never had such a configurability as KDE has. People that like GNOME say that this is simple. Maybe it is for them, but it certainly isn't for me. I usually don't use desktop's defaults and like to have the ability to easy configure my desktop as I wish. KDE provides that for me, other desktops don't. Some other people like defaults, some like to configure its desktops via configuration scripts - as I said: it's a personal preference. \end{religious war over WMs/DMs}
That's why I was initially shocked when I saw Martin's comment that manually changing states will not be needed in KDE SC 4.8. It will always be needed. Removing this would be one step back, one step to the same direction GNOME 3 is going (no offenses ), and I would be very sad about that because I used KDE for a long time and I still today think that KDE 3.5 rocks better than 4.6 but nevertheless I use KDE 4.6 (being on Arch I'm kind a forced to use newest packages, but I don't mind).

[madjr]

And you think that's even technically possible why, exactly?

X11 doesn't have a "full screen" mode. Apps just set their window size accordingly. It's pretty hokey.

The only thing the WM/compositor can really tell is whether an application has a fullscreen, top-level, on-top window or not. Whether that app happens to be a game or a LibreOffice slideshow or a web browser, the WM has no freaking clue.

That is in part why the KWin folks mentioned a NETWM addition for apps to signal whether they want "maximum performance" full screen. That would then finally allow apps to give the WM enough information to make those kinds of intelligent decisions.

Since that protocol does not yet exist, at all, it means that apps will need to be updated.

And that's what happens when you design a half-ass system without thinking things through from the start and relying on "evolving the API over time, hey it's Open Source, we can just update _every damn app in the world_ to comply with the update!"

another solution: let the user decide.

its my freaking computer and am the user, so i should know better which apps i want "maximum performance" full screen.

a simple option or gui for this so i can whitelist the app i want should be enough

[deanjo]

Lower CPU utilization and with it lower battery draining is a real benefit of compositing (no effects need to be active).

I have yet to see lower CPU usage with composite enabled nor have I seen better battery life. Even so it doesn't apply to me as 95% of the time I am on a desktop. For me, personally, a laptop is to confining and limited in capabilities so battery life is for the most part non applicable here.

But I would love to see links that back up your claim.

[Awesomeness]

Or you can use a tiling WM and not need to navigate, because everything is there in front of you all the time.

/begin religious war over WMs

WTF? KWin supports tiling!
Telling KWin users to use a tiling window manager or to get in ?war? with you is like telling Christians to believe in Jesus Christ.

GPU takes power as well.

But less power. It's a well known fact and also the reason GPU-based video decoding is mandatory on pretty much any mobile device because decoding a 720p video on a CPU also drains power beyond belief.

But hey, if you think you alone know better than the entire industry of mobile devices, be my guest and post benchmarks for your claim.

Feel free to post the links to the benchmarks showing compositing extending battery life.

Read Martin?s blog post, for example. He also thinks that disabling compositing is not helping battery life.
Or you can try it yourself: Move a window around fast. On my aging laptop moving my almost fullscreen Firefox window around fast Xorg hogs the CPU with ~40% and the fan kicks in after a minute or so.
With compositing (despite transparency effects, shadows and such) the CPU utilization of Xorg stays low. It's at ~15% on its peak. No fan kicks in (so no overheating GPU and heat is energy which comes from the battery).

I wasn't talking about the specific KWin case, but in general.

This thread is not about compositing in general. It's about KWin specifically.
So again: It makes no sense to completely disable KWin?s composite support if the GPU hardware is capable enough. If the GPU is too weak, KWin doesn't enable compositing automatically anyway. And for fullscreen OpenGL games ? and this is what this news item is about ? KWin will disable compositing automatically for pretty much the only use case compositing affects performance.
But for plain desktop use with a GPU younger than 6 years: Enabled compositing offers no drawbacks ? only benefits.

In fact, I can't care less about what the devs do with KWin, as far as I don't use KDE.

This is a thread about a KWin news item. Leave if you are not interested in KWin.

another solution: let the user decide.
its my freaking computer and am the user, so i should know better which apps i want "maximum performance" full screen.
a simple option or gui for this so i can whitelist the app i want should be enough

You should read the comments in Martin?s blog post. He wrote that it'll be possible to set a window rule to override the automatic composite suspension.

[locovaca]

But less power. It's a well known fact and also the reason GPU-based video decoding is mandatory on pretty much any mobile device because decoding a 720p video on a CPU also drains power beyond belief.

But hey, if you think you alone know better than the entire industry of mobile devices, be my guest and post benchmarks for your claim.

But we're talking Compositing, not video decoding. Nice attempt at a dodge. So I guess you don't have those benchmarks and numbers, eh?

[deanjo]

Or you can try it yourself: Move a window around fast. On my aging laptop moving my almost fullscreen Firefox window around fast Xorg hogs the CPU with ~40% and the fan kicks in after a minute or so.
With compositing (despite transparency effects, shadows and such) the CPU utilization of Xorg stays low. It's at ~15% on its peak. No fan kicks in (so no overheating GPU and heat is energy which comes from the battery).

No difference in cpu usage here.

[mrugiero]

WTF? KWin supports tiling!
Telling KWin users to use a tiling window manager or to get in ?war? with you is like telling Christians to believe in Jesus Christ.


But less power. It's a well known fact and also the reason GPU-based video decoding is mandatory on pretty much any mobile device because decoding a 720p video on a CPU also drains power beyond belief.

But hey, if you think you alone know better than the entire industry of mobile devices, be my guest and post benchmarks for your claim.


Read Martin?s blog post, for example. He also thinks that disabling compositing is not helping battery life.
Or you can try it yourself: Move a window around fast. On my aging laptop moving my almost fullscreen Firefox window around fast Xorg hogs the CPU with ~40% and the fan kicks in after a minute or so.
With compositing (despite transparency effects, shadows and such) the CPU utilization of Xorg stays low. It's at ~15% on its peak. No fan kicks in (so no overheating GPU and heat is energy which comes from the battery).


This thread is not about compositing in general. It's about KWin specifically.
So again: It makes no sense to completely disable KWin?s composite support if the GPU hardware is capable enough. If the GPU is too weak, KWin doesn't enable compositing automatically anyway. And for fullscreen OpenGL games ? and this is what this news item is about ? KWin will disable compositing automatically for pretty much the only use case compositing affects performance.
But for plain desktop use with a GPU younger than 6 years: Enabled compositing offers no drawbacks ? only benefits.


This is a thread about a KWin news item. Leave if you are not interested in KWin.


You should read the comments in Martin?s blog post. He wrote that it'll be possible to set a window rule to override the automatic composite suspension.

First, the thread is about KWin, but the discussion was about compositing in general.
The sentence "Why would anybody not want to use compositing" means "Why would anybody not want to use compositing in KWin" for you?

Second, the hardware might be able to run compositing, but if a crappy driver makes it crash or works buggy, you will want to manually disable compositing. And that will not be solved by the "if the hardware can't run it, KDE does not enables it" feature.
And I'm interested in the technology, I came because of the particular feature added recently, wich is actually a good thing.

[smitty3268]

A modern desktop does mean compositing

but not everyone wants a modern desktop, particularly on Linux.

Don't confuse "good", or "efficient" with "modern." They are different concepts.

[smitty3268]

But we're talking Compositing, not video decoding. Nice attempt at a dodge. So I guess you don't have those benchmarks and numbers, eh?

It's well known that drawing from the GPU is more power efficient than by using the CPU. That's one of the primary uses GPUs are designed around, and they're very good at it.

It doesn't follow that all compositors are therefore more efficient than not having one. In particular, the amount of work being done is often much higher because they add in lots of effects that they didn't bother with on the CPU. So which one uses more power can depend on a lot of different factors, from how efficient the compositor is to what effects you have running and also the apps.