I've also observed much higher CPU usage with KWin while idle.

I can see VRR "breaking" when Steam is open, because it's almost constantly updating its window at the full refresh rate, but it works again once I close it or focus a different window that updates with at least 30Hz

Do you exhibit the CPU usage issue though? On my system, kwin_wayland's CPU usage increases by around 8% even after Steam is terminated. Restarting KWin helps.

I've just checked it with the Show Paint effect: before Steam has ever been opened during a session on an empty desktop everything is fine. After Steam has run at least once, the effect constantly triggers, even on the secondary screen.

Running Steam in gamescope seems to mitigate this problem.

Oh, alright, suspecting that it might be relevant, I unloaded the nvidia driver and removed the card from the PCI tree on my PC, everything is 100% fine now.

I do wonder what Steam is doing with nvidia that is causing this though. Regular PRIME offloading does not trigger this, only Steam seems to do so.

Sorry for the trouble!

One final note though, to whom it may concern: on AMD/NVIDIA systems launching Steam has to be done like so:

VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json steam

This also works.

Ah, unfortunately not - I still had the nvidia driver unloaded. The Vulkan driver choice doesn't seem to matter.

I reported the issue to the Steam issue tracker too: https://github.com/ValveSoftware/steam-for-linux/issues/10847

After further testing, this can also happen when any "custom-border"/"custom-window" Xwayland app (such as FL Studio via Wine, Steam, game/mod launchers via Wine, etc.) is launched.

This in turn forces full refresh rate whole-screen on all screens (unless VRR requirements are met, see below). These full repaints are easy to visualize with the Show Paint desktop effect in KWin.

I've also tried removing the nvidia driver again, this time to no avail - FL Studio manages to trigger this behavior even on a single GPU (AMD) setup, so thankfully it seems like it's not an NVIDIA bug after all. (The Steam window itself for some reason manages to work fine on just AMD, but everything falls apart if I launch a game with "custom" windows, like OMSI 2.)

However, this is probably intended behavior anyway (the minimum refresh rate requirement for VRR is not enforced prior to launching these apps, see https://bugs.kde.org/show_bug.cgi?id=483240, starting one of them "makes it work"). I'll just stick to nested compositing, the Wine Wayland driver and gamescope wherever I can - I'd like to retain full kernel LFC if possible.

The only real issue with these repaints is the relatively "high" CPU usage they cause (compared to when they aren't present).

I've found a reliable reproducer: Yume Nikki on Steam (free). After running the game, the fullscreen repaints are forced on all screens.

This bug can be also triggered via launching "Yume Nikki" (free game) from Steam.

I am experiencing the same issues without running , just running apps that are not wayland native. The apps i have identified so far are :

* All IntelliJ related products (unless i chose JDK-23 and enable experimental wayland support - the app is no longer listed in xlsclients then, and the problem is not present)
* Smath (a mathcad-like application using mono)

I suspect that probably every app that is listed when i run the "xlsclients" command causes this problem

Like i mentioned before running these apps causes sudden slowdown of the entire desktop after some time (like a minute or two). Closing these apps does not resolve the issue. The kwin_wayland process takes around 15% of CPU time, even when showing only wallpaper, but the UI slows down considerably more than these 15% in my opinion.

When i enable the "Show FPS" desktop effect (i do not know why "show paint" effect does not work for me) the "Paint amount" rises to constant 100% and does not go down even if i close every window. 

Issuing "kwin_wayland --replace" solves the issue but also restarts every other application.

I fotgot to add that i am working on hybrid intel/nvidia graphics card but i have the nvidia device removed in udev rules (it was causing suspend/resume problems for me) so it is behaving like only the intel card is present (core i7 11gen)

Changing the window open/close animation to another mode/disabling and re-enabling it (or, to be safe, disabling and re-enabling all desktop effects one by one) seems to fix this issue entirely.

I can confirm that when the issue is present and i changed the window open/close animaton to "Fade" the problem immiediately went away (i could also confirm this on the paint amount graph via the "show fps" desktop effect). So there is a way to get rid of it other than restartin kwin_wayland.
What is more - since i changed the window open/close animation i havent been able to reintroduce the problem in the same kwin session so far...

Does switching back to the Glide effect bring the issue back for you? For me it does; I have to use Scale.

As for me, changing the desktop effect back to glide does not re-enable the problem, at least not immiediately. But for now i have not been able to experience the issue when the window open/close animation is set to "Fade" - this does not mean it will not happen, it may be a pure quicidence.
But i can confirm that changing the animation does fix the issue, it have used this method multiple time s when testing.
I will post my findings here if the effect also occurs when using other animations.

*** Bug 486535 has been marked as a duplicate of this bug. ***

(In reply to fililip from comment #17)
> Does switching back to the Glide effect bring the issue back for you? For me
> it does; I have to use Scale.

I was experiencing something very similar with kwin_wayland suddenly going up to a constant 30-40% CPU. Switching the animation from scale to fade immediately lowered CPU usage to normal. Thanks for the workaround! It's much less painful than having to log out and back every time.

Hello, I was affected by this issue as well. I could reproduce it by simply using VLC or Joplin.

Approximately 10 days ago I read this discussion and I switched the effect from scale to fade. This immediately fixed the problem. Then I immediately switched back to scale and I've been testing for these 10 days. I was not able to reproduce this anymore. It seems 100% fixed so far.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6035

Git commit 64d70029ec74083cb6f481c84dd824a5f4f9aa18 by Xaver Hugl.
Committed on 02/07/2024 at 21:52.
Pushed by zamundaaa into branch 'master'.

plugins/glide: drop references to closed windows if they're not animated

Otherwise the window might still be referenced from the opening animation, which
can lead to the effect wrongly keeping a reference to the window and staying active.

M  +8    -12   src/plugins/glide/glide.cpp

https://invent.kde.org/plasma/kwin/-/commit/64d70029ec74083cb6f481c84dd824a5f4f9aa18

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6037

Git commit ac217c244db439fe3058222c6555f8f3587bae7f by Xaver Hugl.
Committed on 02/07/2024 at 22:05.
Pushed by zamundaaa into branch 'Plasma/6.1'.

plugins/glide: drop references to closed windows if they're not animated

Otherwise the window might still be referenced from the opening animation, which
can lead to the effect wrongly keeping a reference to the window and staying active.


(cherry picked from commit 64d70029ec74083cb6f481c84dd824a5f4f9aa18)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +8    -12   src/plugins/glide/glide.cpp

https://invent.kde.org/plasma/kwin/-/commit/ac217c244db439fe3058222c6555f8f3587bae7f

I re-tested and Glide works fine now in 6.1.3, thanks!