Created attachment 134805 [details] The usual qdbus org.kde.KWin /KWin supportInformation SUMMARY Animations both on X11 and Wayland stutter, no matter the animation smoothness setting. Setting the "force smoothest animation" setting has no effect on making this any better. On Wayland, *everything* stops. Mouse movement, typing, everything. Nothing seems to be excluded from stuttering every 10 seconds or so for about half a second up to 2 seconds. Specially noticeable on mouse movement. On X11 it's not as extreme. It does stutter, but it doesn't pause *everything* when it does so, so I can see what I'm typing, I can move my mouse, etc. On Wayland the compositor just freezes everything every 10 or 15 seconds for like half a second or so. It's extremely bad. Video of the issue: https://youtu.be/5L_kVV2JGPU STEPS TO REPRODUCE 1. Install latest KWin master 2. Start wayland session OBSERVED RESULT 3. Everything stutters a lot. This seems to be hit-and-miss. On my laptop it's *fine*. On my PC it's horribly bad. And my PC is definitely more powerful than my lappy :p I got a video of it: https://youtu.be/5L_kVV2JGPU EXPECTED RESULT At the very least not this amount of stutter, but no stutter would be nice. Mouse movement not stopping. Being able to type a sentence without the compositor stuttering mid-sentence and not rendering what I'm typing until the (1 second or 2 second long) stutter stops SOFTWARE/OS VERSIONS Linux: 5.10.6 KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.19 Qt Version: 5.15.2 ADDITIONAL INFORMATION This is unrelated to 431509 and 431449. Got told to make a new bug, so please don't mark it as duplicate :(
For additional info, my specs are as follows: Ryzen 5 2600, RX 480, 16GB of RAM My laptop, where this doesn't happen (for some reason) it's Ryzen 5 3500U, Vega 8, 16GB of RAM I have both a 144Hz and 60Hz monitor on my main computer. Don't know how much of a difference this'd make on the issue. On further look at the video, this looks more like a lot of dropped frames.
Odd... Does kwin/wayland 5.20.x suffer from this issue as well or is it a regression?
(In reply to Vlad Zahorodnii from comment #2) > Odd... Does kwin/wayland 5.20.x suffer from this issue as well or is it a > regression? 5.20.5 is completely fine.
Also KDE Frameworks version should be 5.79, oops. Dunno if anyone can edit *that* part.
I wonder if it has anything to do with per-screen rendering. If there is only one monitor connected, does the screen still occasionally freeze?
(In reply to Vlad Zahorodnii from comment #5) > I wonder if it has anything to do with per-screen rendering. If there is > only one monitor connected, does the screen still occasionally freeze? Just tried that, sadly it makes no change :(
I tried removing my kwinrc just in case. It didn't make a difference either, just in case. Without a kwinrc the Wayland session took a whole 2 minutes to start. That might be worth another bug report.
After a while of testing and a good minute or two of moving windows, I managed to record it happening on X11 aswell, where there's only one RenderLoop: https://youtu.be/GOkB5Wjx8Ac It's way more rare on X11. And on X11 the mouse keeps moving so it's somehow less annoying.
Can you test kwayland-server and kwin at the following commits kwayland-server: f67daa0711584058a8fefda76e898fe58d53ace7 kwin: 26b249061ee49dacc29320f93984de3d35012e1f this is just to rule out the changes prior to the compositing scheduling rewrite.
(In reply to Vlad Zahorodnii from comment #9) > Can you test kwayland-server and kwin at the following commits > > kwayland-server: f67daa0711584058a8fefda76e898fe58d53ace7 > kwin: 26b249061ee49dacc29320f93984de3d35012e1f > > this is just to rule out the changes prior to the compositing scheduling > rewrite. There's somehow still stutter. This makes me wonder why 5.20.5 works completely fine (just tested that aswell). The stutter is way less, though. There's some stutter, but it doesn't last nearly as long, I can type just fine without the compositor freezing while I'm typing, and the mouse doesn't freeze every 10 seconds or so. X11 has 0 issues with those commits aswell. In short, reverting to those commits makes it better, but there's still *some* stutter. Also 431415 is not reproducible to me anymore after reverting to those commits. The maximize animation now works 100% of the times.
Nevermind. I started playing a video on Youtube and the stutter on Wayland is back full throttle even on those commit hashes. X11 seems... fine, somehow.
Oh wow. This is super cursed. I tried changing the common denominator between my laptop and my desktop: the kernel. Turns out on my desktop I have a kernel optimized for gaming (say, linux-tkg). Well, turns out KWin doesn't like that. At all. Specially on Wayland. Changing to the default linux kernel makes the stutter way less than a second or two freeze, which is super cursed. There's still a lot of frame skips if there's any kind of significant CPU usage, but this whole report seemed to be skewed by that custom kernel using the MuQSS scheduler. I don't think this is completely on KWin's side, so I might just say close it. But as a random test I tested GNOME and it was completely fine. I wonder what causes this difference. I'm sorry for the long report to just come to this conclusion, but might be worth keeping in mind for future issues with KWin on Wayland. Reverting the commits you told me to revert did help with 431415 at least. Thanks you. You can resolve this if you see fit.
(In reply to David Rubio from comment #12) > Oh wow. This is super cursed. I tried changing the common denominator > between my laptop and my desktop: the kernel. > > Turns out on my desktop I have a kernel optimized for gaming (say, > linux-tkg). Well, turns out KWin doesn't like that. At all. Specially on > Wayland. > > Changing to the default linux kernel makes the stutter way less than a > second or two freeze, which is super cursed. There's still a lot of frame > skips if there's any kind of significant CPU usage, but this whole report > seemed to be skewed by that custom kernel using the MuQSS scheduler. > > I don't think this is completely on KWin's side, so I might just say close > it. But as a random test I tested GNOME and it was completely fine. I wonder > what causes this difference. > > I'm sorry for the long report to just come to this conclusion, but might be > worth keeping in mind for future issues with KWin on Wayland. Reverting the > commits you told me to revert did help with 431415 at least. > > Thanks you. You can resolve this if you see fit. To be clear: there's still frame skips and stuttering. It's just not as bad as the original video shows.
Though, after changing what I told you, VSync is still absolutely wrong on XWayland apps: https://i.imgur.com/df82B3i.png And Chromium running natively on Wayland isn't any better: https://i.imgur.com/chVQSBR.png This is on a 144Hz monitor, aswell.
While vsynctester.com is quite useful, I don't think that its results are trustworthy in all cases. I've checked it with different browsers (with and without wayland native support), no single browser was showing consistent measurements. It's also worth mentioning that Firefox's frame rate is capped due to a bug in Xwayland. There is weston-simple-egl tool that measures the frame rate based on frame callbacks, it's not accurate, but it's good enough.