KDE's KWin Compositor Sees Near Total Rewrite Of Compositing Code.

[bearoso]

I've read comments on that merge request and latest was "its a good idea to look into mutter or kwin-lowlatency to see how they avoided stuttering". So no changes for me - I will continue using kwin-lowlatency

It doesn’t look like they learned anything. They include an option for either low latency or smooth motion. It should just be both at once.

[andreduartesp]

Disabling compositing so your game runs well sounds more like a bug then something you should so. Gnome handles that correctly.

KWin can do both ways, many old games don't properly ask for unredirect to the compositor, in this cases GNOME doesn't give you any choice, but on Plasma, you can enable a feature on Kwin to disable the compositor with certain rules. The most common rule used out there is to disable compositing to any fullscreen software.

[andreduartesp]

So, find a bug in KDE, learn C++. Find a bug in Gnome, learn C. Find a bug in your game, learn Unity/C# or Android development. So simple, why didn't I think of that?

The point of open source is anyone having the time and the skills can help. Not that everyone hit by a bug should be directed to learn how to program or shut up.
Hell, there are companies built around open-source code bases precisely because the users need support and bug fixing, despite the code itself being freely available.

You don't need to learn the language or the code base, you can pay for someone with the skill to fix it for you (and that's the reason people build companies around open source code). What is absurd, is to expect to someone with other needs end other perspectives to work for free on a problem only you are facing.

[andreduartesp]

It doesn’t look like they learned anything. They include an option for either low latency or smooth motion. It should just be both at once.

You can't do both, to do a smooth animation you need to introduce some latency. You can be in the middle-ground, but you can't do both with quality at the same time. Since KDE is about choice, the better solution is to keep this decision on the user's hand.

[bearoso]

You can't do both, to do a smooth animation you need to introduce some latency. You can be in the middle-ground, but you can't do both with quality at the same time. Since KDE is about choice, the better solution is to keep this decision on the user's hand.

Yes you can do both. kwinft and mutter both work smoothly for me with very low latency. It's a shame that users have to compromise so another set of developers can learn the proper ins and outs of compositor programming, but that's Wayland's fault for shunting a lot of hard technical work to the UI programmers.

[Kver]

Yes you can do both. kwinft and mutter both work smoothly for me with very low latency. It's a shame that users have to compromise so another set of developers can learn the proper ins and outs of compositor programming, but that's Wayland's fault for shunting a lot of hard technical work to the UI programmers.

The new Kwin code is doing the *exact* same thing. Exact. PLUS one thing people are missing that might be very, very interesting. They're just also exposing an additional control to let you either ride closer to the edge of missing a frame. I've written several game compositors at this point, and this new code (based on the conversation) is offering *more* than the compositors you mentioned.

With any compositor there's 3 things you tend to watch to optimize input latency.

1. The time the frame must be completed
2. The time it takes to render your scene (in this case, desktop)
3. The time you have to collect input.

In an ideal perfect world, you know the first two points letting you collect input data until the very last microsecond. But in the real world you don't know how long the scene will actually take to render. So when you're building out a compositor you have to guess; and you guess by looking at the performance of previous frames. So you take a sample of frames, see how long those took, put it into a weighted curve, and you have your guess. Even then you aren't "safe" though, maybe the desktop has been idle for the past several frames and the frame you're about to render has the beginning of a new animation not previously in the scene. If that is happening, the frame will take longer to render, and you've missed your deadline, and everything either stutters or tears.

So *every* compositor must add a safety buffer, a little extra time in case something interesting happens. Mutter does it. KwinFT does it. In the case of these two projects they are picking how "safe" they want to be, and whatever they've chosen is out of your control. If you're "too safe" you get latency, if you ride the edge you get stutter. Gnome probably leans on the safer side, and KwinFT probably sits somewhere in the middle. The only thing this update is doing differently is letting you - the user - pick how safe you want to be. This is the kind of setting you might see in AAA games.

And that makes sense to me. A twitch gamer might be more interested in riding the latency line. A desktop web browsing user might be more interested in persistent butter-smooth animations. Heck, casual gamers that don't need twitch input might prefer more frame stability. All that being said, Kwin will probably default to somewhere in the middle, maybe leaning on the safe side. I'd argue exposing this as an option at all isn't just matching something like mutter, but goes "above and beyond". If you have a powerful graphics arrangement and CPU behind you, you can absolutely push yourself closer to that edge, and that's something only you - the user - can make that call on.

Edit: One thing I'd be interested in seeing is this exposed further as a documented API for Kwin scripts and/or windows rules. This way when you're just using your desktop you might default to a nice stable cozy framerate, but if someone kicks up CS:GO it might try to ride that line a bit harder. If it were a stable API then projects like "Game Mode" could hook into this, too.

Anyway, one very interesting thing I saw in that was animation advancement. This has the possibility of being very - VERY - good if it is what I think it is.

When compositing a frame, every animation handled by Kwin can be thought of as having "tweens". Tweens have a start value, end value, and a time delta value. If for example a window is gliding in, it will have a start state, end state, and by taking the time delta you find current state; such as where in the glide animation a window is on a given frame.

On most compositors when the rendering starts it either captures the current time or keeps sampling the clock as it goes. If I interpret the notes correctly, they are timing ahead of the current system clock (either by getting the vblank time or extrapolating from the current time). Without this if you click a button that glides in a window, depending on how it samples the time, the gliding animation might be out-of-date before it even begins compositing. So even if a 'stupid' compositor times the start of rendering perfectly, you might still perceive lag relative to the render time and frame time. This update won't have that problem.

You know the old saying "don't aim for where the target is, aim for where the target is going to be"? Essentially it sounds like Kwin is going to start doing this, too. Now, this isn't a silver bullet, there's limits to what you can look ahead for, but you can expect things like panel popups, window animations, and hover effects in some cases will not only be rendered with very little input latency - but will also be rendered in anticipation of when the frame will actually hit your screen. If that's the case, it's literally going to be presenting some things with exactly 0 latency.

Edits; grammar, clarification, etc.

[dragon321]

Disabling compositing so your game runs well sounds more like a bug then something you should so. Gnome handles that correctly.

In some cases it can be useful so that's why I think it should stay as option. Undirection should be default behavior.

KWin can do both ways, many old games don't properly ask for unredirect to the compositor, in this cases GNOME doesn't give you any choice, but on Plasma, you can enable a feature on Kwin to disable the compositor with certain rules. The most common rule used out there is to disable compositing to any fullscreen software.

KWin doesn't support fullscreen undirection so it cannot do both ways. Disabling compositor is only option both for windowed and full screen applications. KWin supported full screen undirection but it was removed because it was "broken". KWin-lowlatency fork brings this feature back along with many improvements to the KWin compositing. GNOME surely has flaws but Mutter does compositing better than KWin. I hope KWin will catch it after rewrite.

[doomie]

Also, as it was already written, there are other ways. For example, Edward Snowden recently asked for donations to the EFF (https://www.eff.org/deeplinks/2020/1...-broken-system), for Libreoffice you can use [crowdfunding](https://wiki.documentfoundation.org/Crowdfunding) to setup a bug bounty, etc.

THIS! It's a free market solution! The only reason I haven't done this kind of thing for KDE fellas is that I am far far too poor ATM. This concept could save gaming in the future if done right.

[bug77]

You don't need to learn the language or the code base, you can pay for someone with the skill to fix it for you (and that's the reason people build companies around open source code).

That doesn't work for KDE, where many bugs come from Qt or video drivers. KDE devs do take care of Qt when they can, but they won't fix a driver bug for you.

What is absurd, is to expect to someone with other needs end other perspectives to work for free on a problem only you are facing.

Yeah, what do you know, most bugs hit more than one person, so I'm not the only one seeing them. Honestly, I have people commenting on the (admittedly few) bugs I submitted, telling me they see the same problem. On one of them a dev tells me he can't reproduce the bug (but won't tell me what he actually tried), on others the devs don't even chime in.

Don't get me wrong, KDE is the DE for me. But since I have tried "contributing" by submitting bugs, the project has suddenly started looking like a place where people fresh out of school are just building up their resumes. And yes, I am fully aware that even that is the case, there are at least some developers over there that are way, way better than that.

[shmerl]

Sounds good, but what about collaborating with KWinFT? Will that ever happen or the two projects completely diverged?