I wanted to report this as a bug but I’m posting it here first.
I’m testing with 2 idle games. (Unnamed Space Idle and Realm Grinder)
Both games have a timer and usually this timer should advance accordingly even when the process is in the background.
This holds true for X11 but in Wayland it’s not the case.
Confirming this problem in htop, X11 advances the CPU time+ at the same pace in the foreground or in the background. This is the intended behaviour.
In Wayland, as soon as the process is in the background, the CPU time+ is only advanced minimally which makes both games not operate correctly anymore. The ingame timer starts to drift and even stops advancing completely.
For Unnamed Space Idle this means the timer completely stops advancing after 3 seconds in the background.
I’ve searched around how Kwin/Wayland handles background processes or if there’s a config for it to prevent it but I found zero information on this.
So if anyone has any idea how to deal with it, please tell but I do think this is quite the severe and widespread bug. It’s not specific to KDE, I had the same thing in Gnome and Hyprland too.
This sounds like a bug in the game TBH — especially if you see the issue in GNOME, Hyprland, and Plasma.
A lot of X11-using apps got used to doing really weird things that worked on X11, and that don’t work on Wayland. XWayland provides some level of compatibility, but it will never be perfect.
If it was isolated to one engine I would agree but this is happening for Unity, Godot or the Adobe Air framework in the case of Realm Grinder.
There are also problems related to multiplayer games or Elden Ring. In the case of Unity I wrote a simple test app that just shows the ElapsedTime variable. 30 realtime seconds turn into 10 elapsed seconds. (I can post the build if anyone is interested, Unity Runtime is able to run in XWayland and native Wayland)
I found this very heated discussion that is related to the problem: “Guarantee 1Hz progress for FIFO present mode” (mod edit: inserted link in lieu of enzi who still lacked permissions)
I see is lots of deflection with no solutions who is even responsible.
What I do know is that it’s a 100% related to Wayland. Gnome and KDE in X11 work fine, as soon as you switch to Wayland the problem appears. Hyprland, well it doesn’t run in X11, so not much to compare to.
Anyway, I really want to know who I have to bug with this problem. Wayland overall has been a straight up terrible experience, starting from decorators, mouse warps to apps getting suspended that are not supposed to be fully suspended.
Is the KDE team able to do something about with a possible fix in KWin?
This is a problem in Xwayland, it throttles apps to 1Hz when frame callbacks don’t arrive / when the window isn’t visible.
KWin could always send frame callbacks for all apps, but that would also mean all background apps always use CPU and GPU power unnecessarily, which is not great.
If you don’t want an app to throttle, the easiest solution is to not minimize it, or put it in gamescope.
What if those 2 things are not an option? Is there not a more elegant solution possible?
I can agree on that KWin shouldn’t send frame callbacks all the time by default, but what if the app would be able to request it or it’s an user option globally? (Sidenote, does KWin for X11 send frame callbacks all the time? I suppose it does from my testing)
Unity has a player setting “Run in background” for exactly that behavior otherwise the game is paused and the game loop doesn’t run.
In the case of Windows, when a game/app is minimized it draws a LOT less CPU/GPU power but is still able to maintain the simulation loop. What are they doing that Wayland can’t mimic?
That’s not how that works. Throttling is opt in from the app, it could trivially do the opposite.
That might not be the worst idea.
KWin is not involved in frame pacing on Xorg at all, but when a display is turned off, Xorg does the exact same thing as Xwayland and throttles apps to 1fps.
They probably throttle to a bit more than 1Hz, if at all.
@Zamundaaa I tested this further and made a Unity app for it. A build can be found here: (still can’t link) files .enzenebner.com/LinuxTimerTest.zip
optional: Start with “-force-wayland” so experimental wayland is used (I say optional because it happens in XWayland too)
let game run for some seconds, the elapsed time is displayed.
at around 10 seconds put the game in the background
have a clock running or count yourself for 30 seconds
put game in foreground, elapsed time is ~20 seconds but it should show ~40 seconds.
(pro testing move, just check htop for CPU time, when the cpu time goes to 0 or near 0 the timer starts to drift from the real time)
The interesting part here is that I can’t reproduce (anymore) with just minimizing the window and only with either switching desktop or activity.
Gnome and Hyprland is also consistent in this behaviour.
Do you know why it’s acting so differently? I was expecting the same behaviour either minimized or on another desktop.
With Xwayland, there can be a difference because the window gets unmapped on minimize, instead of just not receiving frame callbacks anymore… but there should not be a difference with Wayland native windows, they don’t even get told whether or not they’re minimized.