Created attachment 168770 [details] Showing the low refresh rate animations and scrolling. Environment: Operating System: Arch Linux KDE Plasma Version: 6.0.4 Application: KDE Discover KDE Frameworks: 6.1.0 Kernel Version: 6.8.7-arch1-1 (64-bit) Qt Version: 6.7.0 Windowing System: Wayland CPU: Ryzen 7 5700 GPU: RX 6700XT RAM: 32GB DDR4 SUMMARY When using the overview animations, the window snapping animations, or scrolling in system settings, the frame rate seems to be capped at 60hz, even though I have the refresh rate set to that of my monitor, 165hz. Additionally, when scrolling in system settings the scrolling on the sidebar suddenly becomes a higher refresh rate when the "Colors and Themes" option is clicked. STEPS TO REPRODUCE 1. Using a high refresh rate monitor, set the refresh rate of plasmashell to the highest refresh rate. 2. To find the scrolling issue, open system settings, and start scrolling on the sidebar, then click Colors and Themes, and back to the main menu, then start scrolling again, it becomes smooth. 3. Either open the overview or snap a window to the side to see how stuttery they look compared to the same animations in either GNOME or Windows 10/11. OBSERVED RESULT Animations that are for some reason capped at 60hz. EXPECTED RESULT The animations should happen at the set refresh rate. ADDITIONAL INFORMATION: The animations all appear to be smoother on x11 then wayland, which is odd, because everything else is smoother on wayland for me.
I've encountered the same behavior on my 240hz display. The overview and window snapping animations are the most noticeable, and appear (mostly) correct on the X11 session. Peculiarly, the overview animation on the X11 session renders at a lower framerate *until* a window is snapped to an edge, following which it will begin rendering at the correct framerate. I found a user on Reddit: https://old.reddit.com/r/kde/comments/1c1lkiw/strange_lag_symptoms_with_the_overview_effect/ who reported similar issues (along with the quirk in the X11 session I described). > Additionally, when scrolling in system settings the scrolling on the sidebar suddenly becomes a higher refresh rate when the "Colors and Themes" option is clicked. I was able to reproduce this as well.
Can still reproduce on 6.1. So far, I've found the overview, desktop grid, cube and new edit mode to be affected. With a 165hz monitor and a 60hz one right beside it and spamming the overview, it is very obviously running at 60hz. Even if I boot with only the 165hz one physically connected, the problem persists. I have verified with the 'Show FPS' effect that the desktop barely drops frames when activating any of these effects. Couple notes for the overview: - Switching to another workspace (clicking, arrow keys, shortcut) in the overview also runs at 60hz. In comparison, the 'slide' effect when switching virtual desktops outside the overview is significantly smoother. - When dragging a window here, the window moves at the correct framerate. The new edit mode is also interesting, because the animations for entering and exiting it are visibly choppy (seemingly below 60fps even), while the animation that plays when opening a panel configuration (desktop being pushed away to make space) is hilariously smooth in comparison. The animation for opening the 'Add widgets' sidebar for example also runs at the correct framerate. Regarding the scrolling, I've tested a couple applications that have smooth scrolling. Not scrolling at the correct framerate: - System Monitor/Info Center - Dolphin (the F3 sidebar sliding animations is also running at 60hz) - Okular Scrolling at the correct framerate (extra notes for these below): - System Monitor (process tables) - Discover - Emoji selector - Filelight (sidebar) - Clipboard applet (needs a plasmashell restart as well after applying below fixes) If I boot with a secondary 60hz monitor enabled, these applications also have the 60hz scrolling. If I turn that monitor off and then on again, they seem to be fixed until next reboot (this fix seems to persist even through logging out). If I boot only with the 165hz one connected, they are fine. Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 Kernel Version: 6.9.4-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 7600
(In reply to DT from comment #1) > I've encountered the same behavior on my 240hz display. The overview and > window snapping animations are the most noticeable, and appear (mostly) > correct on the X11 session. Peculiarly, the overview animation on the X11 > session renders at a lower framerate *until* a window is snapped to an edge, > following which it will begin rendering at the correct framerate. I found a > user on Reddit: > https://old.reddit.com/r/kde/comments/1c1lkiw/ > strange_lag_symptoms_with_the_overview_effect/ who reported similar issues > (along with the quirk in the X11 session I described). > > > Additionally, when scrolling in system settings the scrolling on the sidebar suddenly becomes a higher refresh rate when the "Colors and Themes" option is clicked. > I was able to reproduce this as well. Same here. I've had this problem with the overview effects and desktop grid since 5.XX. For X11 I created a post-login script to Alt-tab automatically as fast as possible (this brings the same effect than a windows snapped) and the animations were amazing again, however, that workaround has never worked on Wayland. It would be great if some day this issue could be solved, it looks difficult and probably the priority is low due to the effects are pretty functional as they are, but for me I have been searching for a solution, even I was thinking on thinkering the effects by myself, but in KDE6 they are not in the effects folders anymore.
I encountered the same issue on wayland, with 165hz monitor, AMD RX 6600 XT, Plasma 6.1.5 on kernel 6.10.10. On X11 the animation is smooth, but every startup, I have to unsnap and snap a window to make it smooth, otherwise it's stutter. Basically like others mentioned.
Can confirm that the issue persists in Plasma 6.2. As a laptop user this feels more noticeable especially when the using touchpad gestures to scroll through the desktops in overview mode. Operating System: Aurora 40 KDE Plasma Version: 6.2.1 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.11.3-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 22 × Intel® Core™ Ultra 7 155H Memory: 15.0 GiB of RAM Graphics Processor: Mesa Intel® Arc Manufacturer: HP Product Name: HP Spectre x360 2-in-1 Laptop 14-eu0xxx
Still hasn't been fixed as of KDE Plasma 6.2.2.
I get strange behavior on X11, It is "low refresh rate" when I log in, but it somehow fixes itself after like two minutes, and then it is silky smooth. However, the same cannot be said for Wayland.
(In reply to copilexp from comment #7) > I get strange behavior on X11, It is "low refresh rate" when I log in, but > it somehow fixes itself after like two minutes, and then it is silky smooth. > However, the same cannot be said for Wayland. Nope, seems to be triggered by something.
It looks like these animations are all being driven by QUnifiedTimer, which uses a shared global tick, and the tick interval just defaults to 16ms. And if some component ends up calling QUnifiedTimer::setTimingInterval(), it would affect other animations since it's shared. It might explain why it fixes itself sometimes. If I apply the attached patch to qt6-base to change to default tick interval to 6ms, all the animations look smooth on my 144hz display (overview effect, system settings scrolling, the smooth scrolling in okular).
Created attachment 176255 [details] hack to increase qt6 animation tick
At first glance, this works. Boy howdy! May also resolve BUG 455585, BUG 493208
*** Bug 493208 has been marked as a duplicate of this bug. ***
This has been bothering me for a while, thanks for the find! With the patch it's much, much better now.
WOW! This completely solves everything!!! I'm still kind of new to the whole Linux bug submitting experience, and I assume this is upstream with qt. Does anyone know who I have to contact in order to upstream this?
Tried the patch on my system, X11 and Wayland both butter smooth now. (I used 4 ms to have a high enough refresh rate for a 240 Hz monitor). Arch Linux KDE Plasma: 6.2.4 KDE Frameworks: 6.8.0 Qt: 6.8.1 Kernel: 6.12.1-arch1-1 AMD Radeon RX 6950 XT
> I assume this is upstream with qt. Does anyone know who I have to contact in order to upstream this? A case can be opened at https://bugreports.qt.io/projects/QTBUG/issues, buuuuut...... This is still technically an issue with Kwin or whichever component is responsible for setting the timing interval properly. Changing the default lib value works (and it works beautifully), but it's still just a hack to prove this works. The value likely will need to be calculated dynamically based on monitor hz. > It looks like these animations are all being driven by QUnifiedTimer I'm curious how you found this! I've been scouring the plasma codebase and can't find anywhere that QUnifiedTimer::setTimingInterval() is referenced, or even portions of it. I checked user-installed plasmoids and other locations as well. If it can be properly set and retained globally as Kwin starts, it would have the same effect as changing the default upstream.
(In reply to Blazer Silving from comment #16) > > It looks like these animations are all being driven by QUnifiedTimer > > I'm curious how you found this! This was bothering me, so I was grepping around in the qt code for potential culprits. QUnifiedTimer does seem to be a private API to qt. It could be that the animations that never have this issue are driven by something else. But at least in the case of system settings, it does _something_ that ends up fixing this (maybe in kirigami?).
It's great having a possible solution for this issue!!! Thanks!!!. Just a quick question, is there any guide about how to patch qtbase and reinstall it, so I can also test this? I have been googling a little bit and I found the repo and the file for qt, but I still don't know how to replace qtbase so this fix could work. Any information would be really appreciate it. (I am using Fedora KDE 41 right now)
(In reply to n.parkanyi from comment #17) > (In reply to Blazer Silving from comment #16) > > > It looks like these animations are all being driven by QUnifiedTimer > > > > I'm curious how you found this! > > This was bothering me, so I was grepping around in the qt code for potential > culprits. QUnifiedTimer does seem to be a private API to qt. It could be > that the animations that never have this issue are driven by something else. > But at least in the case of system settings, it does _something_ that ends > up fixing this (maybe in kirigami?). It bothered me too, especially how intermittent the behavior seemed to be. This does cover the behavior described in BUG 455585 that we'd been tracking for some time. Great find, for real. This may indeed be an upstream QT bug that needs to be filed and looked at officially, they may have pointers on how to better handle it on the KDE side as well. (In reply to Orlando Rodriguez from comment #18) > It's great having a possible solution for this issue!!! Thanks!!!. Just a > quick question, is there any guide about how to patch qtbase and reinstall > it, so I can also test this? I have been googling a little bit and I found > the repo and the file for qt, but I still don't know how to replace qtbase > so this fix could work. Any information would be really appreciate it. (I > am using Fedora KDE 41 right now) The quickest way to test a one-line fix like this is to build a patched package for your distro, and install it over the system version. Most offer tools and helpers for this (PKGBUILD for Arch, fedpkg for Fedora, etc). Generally the package manager will overwrite the patched version on the next repo update. Even cooler is setting up an isolated container to do the build, so you don't have to install all the build dependencies on your main system :)
(In reply to Blazer Silving from comment #19) > The quickest way to test a one-line fix like this is to build a patched > package for your distro, and install it over the system version. > Most offer tools and helpers for this (PKGBUILD for Arch, fedpkg for Fedora, > etc). Generally the package manager will overwrite the patched version on > the next repo update. Even cooler is setting up an isolated container to do > the build, so you don't have to install all the build dependencies on your > main system :) Thank you so much!! I was able to apply the path by using fedpkg (I did not know about it). And for me it works really really well. Now KDE looks just AWESOME!!! Big difference in my desktop machine with 144hz monitors.