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

[Sonadow]

Don't get me wrong, I want progress to materialize sooner rather than later, but I find it interesting that there is a huge outcry when CPU ISA support is concerned but not so much in the GPU space. A Vulkan-only desktop world would leave Sandy Bridge iGPUs and AMD-VLIW architecture based products and everything older in the dust. That would translate into mandatory AVX support in the CPU world for a central piece of software. If there was a method to support these older products under Vulkan or keeping an OpenGL-path for these that would be fine but breaking these users would also mean to deny users of these older products to still participate in general (one could start to deprecate all older tech in the Kernel and elsewhere though, that might be a plus for some to modernize the technical foundation in general).

It will also exclude anybody on the Nouveau drivers which still does not provide Vulkan. Users like me.

[Steffo]

Is this incorporating any code or general concepts from the Wayland KwinFT fork?

https://www.phoronix.com/scan.php?pa...DE-KWin-Forked

This is a dead project the moment it has been forked, even if the intention were good.

[Guest]

Vulkan is definitely the future, so I wouldn't worry about old devices in the sense of "let's not support Vulkan because of that".

Oh sure, I'm not saying it's an excuse to not support Vulkan. I definitely think Vulkan support is important, and the future (I'd rather it was already in use everywhere).

[ms178]

It will also exclude anybody on the Nouveau drivers which still does not provide Vulkan. Users like me.

Right, I missed these users. But at least the technical capability is there on Kepler+ to support it if these users were willing to use their non-open driver.

[unic0rn]

There's absolutely no point in moving towards Vulkan support when the OpenGL path is messed up. Vulkan won't magically make anything faster and compositor isn't an AAA-class game engine to benefit heavily from such switch, if at all. From the hardware compatibility perspective, OpenGL support is required anyway, and I say that as someone with a hardware that supports Vulkan.

The whole "this or that is the future" BS should stop. Wayland is a perfect example - still not a usable option unless you're using Gnome. Doesn't stop the hype train, which in turn cuts X11 users off from some fixes/features or delays access to them (Firefox/EGL/vaapi mess for example). The focus should be on things that are accepted as working well for the majority of users. I'm not saying to ignore Wayland or Vulkan, but when Compiz had better performance on a Geforce 4 MX (perfect 60fps with several things - including a video and a game - running) than KWin has on a much faster hardware, there's a problem and that problem is neither X11 nor OpenGL, it's the code quality.

[clapbr]

Does anyone around here actually tested if this fixes the stutters? Too much noise...

[theriddick]

I recently moved back to kwin-git on arch, not sure if it has these updates, but I use tearfree mode and don't notice really much or any stutters. If I disable tearfree however, sure lots of nasty stuff happens. Also I use freesync mode on which kinda does the same thing if the app uses OpenGL.

I was using kwin-lowlatency but for some reason it would frequently cause a screen tear on the bottom 1/3th of the screen requiring either a resolution or refresh rate switch back/forward to resolve (such a weird issue). It was related to VRR feature but so far hasn't occurred with kwin-git... touch wood...

[slacka]

This is a dead project the moment it has been forked, even if the intention were good.

It's very much alive: https://gitlab.com/kwinft/kwinft/-/commits/master/

The question is can the improvement in kwinft be merged back into kwin? We seen much larger project like WebKit merge improvement from Chrome. The questions are how much of a rewrite was this really and is there the will/man;power in kde to merge these kwinft improvements back in?

But you're right. There is so much duplicate effort in opensource software from forking. I see it all the time. It's just the nature of beast. There are so many projects I've seen forked that would have achieved more by working together. Case in point, as an old Mandrake user, it's frustrating that the 2 major forks OpenMandriva and Mageia both lack developer resources. Debain has a million forks and is constantly in need of maintainers.

[theriddick]

Its difficult to get new ways of doing stuff or 3rd party work arounds or fixes merged into a mainline project, just look at Wine vs Wine-Staging, just so many fixes stonewalled.

[bug77]

I wouldn't mind a Vulkan-only, Wayland-only rewrite of KWin.

Keep a legacy X11 "KWin Classic" around for non-Vulkan and/or non-Wayland (or XWayland) setups but focus on cutting out some old program concepts that are restricting future features (dynamic framerate, 10/12-bit displays, multi-monitor multi-framerate, low latency, reduced memory usage and churn because some unnecessary libraries can be removed or trimed down, ...)

Consider standing on other projects shoulders if it makes sense (e.g. wlroots (wayfire says this)) to reduce duplicated work and create a larger foundation. If the goal is to create a valuable product, seek for partners and synergies. This also increases team-size and delegates responsibilities.

Vulkan will Soon (tm) be the base for nearly everything short- or long-term (see Zink, DXVK & Co)

You haven't been paying attention then. Martin Graesslin himself said kwin was built around X and will stay like that forever. Should you ever need something Wayland only, you should start from scratch (his words).

Vulkan would be nice but:
a. a DE is not heavy enough to worry about CPU overhead
b. I don't think Vulkan drivers are vetted enough at this point
c. Vulkan support is coming with Qt6 anyway