Bug 431546

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.