SUMMARY Since 6.0, some animations are not playing at the monitor's refresh rate. My monitor is 120Hz, but some animations very clearly play at a lower framerate (if I had to guess, I'd say around 60Hz). Affected animations that I've encountered thus far are: - Present windows - Desktop overview (meta + W) If it matters, my monitor has a pretty high resolution of 7680x2160 STEPS TO REPRODUCE 1. Be on a monitor with at least 120Hz refresh rate 2. Play one of the animations listed above OBSERVED RESULT The animation plays at a lower framerate than 120Hz EXPECTED RESULT The animation plays at 120Hz (assuming the hardware is capable enough) SOFTWARE/OS VERSIONS Linux/KDE Plasma: NixOS (available in About System) KDE Plasma Version: 6.0 KDE Frameworks Version: 6.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION -
What GPU do you have?
AMD RX 7900 XTX
I can confirm that the same thing is happening to me since upgrading to KDE Plasma 6. Enabling Show FPS shows that the desktop is consistently running at 90 FPS, but as soon as I initiate Desktop overview it drops down to a consistent 60 FPS. intel_gpu_top indicates no stress on the GPU, CPU is also not under load, even on a single core. Furthermore, using touchpad gestures to initiate the overview seems to sometimes be 60FPS, sometimes the expected 90FPS. In case it helps: Operating System: Arch Linux KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.6-arch1-2 (64-bit) Graphics Platform: Wayland Resolution: 2880x1800@90Hz CPU: Intel Core i7-1370P GPU: Intel Iris Xe Graphics, i915 driver. RAM: 32GB
Affected people, can you try again with Plasma 6.0.1 which was released yesterday? There were some fixes for this issue.
(In reply to Nate Graham from comment #4) > Affected people, can you try again with Plasma 6.0.1 which was released > yesterday? There were some fixes for this issue. Issue is still present, reporting and appearing at 60 FPS despite the monitor being at 90Hz on Plasma 6.0.1.
Same for me, same animations are still affected. Behavior doesn't seem to have changed.
Actually, scratch that. The behavior *did* change, in that the FPS counter now doesn't drop to around 60ish anymore. However, the animations still play at a notably lower frame rate than everything else (e.g. moving windows manually). I wonder if this could be related to Bug 482035 ? Could be a Qt bug perhaps.
Any further improvement with Plasma 6.0.2?
Also, can you reproduce this issue anywhere else other than Overview and Present Windows? They're known to have some performance bottlenecks right now/
If my caveman eye is to be trusted, I'd say the overview effect now plays at (or very close to) my monitor's actual refresh rate (120Hz). However, the present windows effect still looks a little sluggish to me. I'd say maybe around 80-90 fps? It's hard to say, since the frame counter happily reports 120Hz, even though that's very obviously not what's being displayed, weird. It's definitely improved though, I'll say that much. As for any other places, these are the two effects I use most. I haven't noticed it on any other ones (e.g. switching desktops with Meta+Ctrl+Right/Left is perfectly smooth at 120Hz).
Ok, great. Overview's performance is known and being worked on constantly, so it sounds like there isn't a general issue here anymore, just that specific one. Closing.
(In reply to Nate Graham from comment #9) > Also, can you reproduce this issue anywhere else other than Overview and > Present Windows? They're known to have some performance bottlenecks right > now/ I have noticed that the logout screen (also known as Leave) runs at 60 FPS including mouse cursor. It seems like full screen effects with heavy blur involved are what is predominantly affected here. Disabling blur fixes the issue on the logout screen and is 90 FPS. Disabling blur, however, does not disable the blurring nor fix the performance in Overview and Present Windows.
the Logout screen is another known performance bottleneck, yeah. There's a slow shader providing the blur there.
Does there already exist a bug report for the present windows effect then, or should I open a separate one for that?
It's more of a known issue among the devs that's being actively worked on; not sure we need a bug report for it.
Git commit d59451adcf8f7a4d90659a60bfbe73230091b0e3 by Xaver Hugl. Committed on 26/03/2024 at 16:06. Pushed by zamundaaa into branch 'master'. effects/quickeffect: render qtquick scenes in the normal render pass If they're rendered in prePaintScreen, the time needed to render them is not accounted for in compositing scheduling, which may make KWin miss vblank Related: bug 482861, bug 452119 M +5 -0 src/effect/offscreenquickview.cpp M +9 -10 src/effect/quickeffect.cpp https://invent.kde.org/plasma/kwin/-/commit/d59451adcf8f7a4d90659a60bfbe73230091b0e3