Created attachment 134785 [details] Attaching the usual qdbus org.kde.KWin /KWin supportInformation SUMMARY Hi, I'm using kwin-git. Before these animations were smooth. But after this https://invent.kde.org/plasma/kwin/-/merge_requests/507 patch, the animations are laggy. STEPS TO REPRODUCE 1. open and close animations OBSERVED RESULT i test all options in latency in compisiting settings. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.9.16-1 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530 Monitor: Single 1920x1080 60Hz
Do animations lag if you choose "prefer smoother animations" in compositing settings?
(In reply to Vlad Zahorodnii from comment #1) > Do animations lag if you choose "prefer smoother animations" in compositing > settings? Yes, But before this patch were very smooth.
Can you try running kwin with KWIN_USE_INTEL_SWAP_EVENT=0?
(In reply to Mojahed Yavazi from comment #2) > (In reply to Vlad Zahorodnii from comment #1) > > Do animations lag if you choose "prefer smoother animations" in compositing > > settings? > > Yes, But before this patch were very smooth. When open a window, Animations like sliding popup or minimize are laggy.
(In reply to Vlad Zahorodnii from comment #3) > Can you try running kwin with KWIN_USE_INTEL_SWAP_EVENT=0? I test this enviroment variable and animations are smooth!
My guesstimate is that the animations for some reason don't run with the real vsync frame rate.
(In reply to Mojahed Yavazi from comment #5) > I test this enviroment variable and animations are smooth! I might have an idea what's wrong with swap events. If I create a patch, will you able to test it?
(In reply to Vlad Zahorodnii from comment #7) > (In reply to Mojahed Yavazi from comment #5) > > I test this enviroment variable and animations are smooth! > > I might have an idea what's wrong with swap events. If I create a patch, > will you able to test it? Yes
Okay, I tried "force smoothest animations" and I still saw lag. So I ran VSync tester and... I'm not crazy, everything is stuttering a LOT. I was like okay I might have to turn it a notch more. I will. It didn't make a dent, everything is still absolutely not-having-it, and this is on Wayland, both for Wayland and X11 clients, VSyncTester has the same effect on either. Proof: https://i.imgur.com/P9kUMdz.png
(In reply to David Rubio from comment #9) > Okay, I tried "force smoothest animations" and I still saw lag. So I ran > VSync tester and... I'm not crazy, everything is stuttering a LOT. > > I was like okay I might have to turn it a notch more. I will. It didn't make > a dent, everything is still absolutely not-having-it, and this is on > Wayland, both for Wayland and X11 clients, VSyncTester has the same effect > on either. > > Proof: https://i.imgur.com/P9kUMdz.png I'm running an AMD RX 480. So the env variable sadly makes no difference to me. On Wayland I can tell the stuttering as I'm typing this and every 5 words it stops rendering me typing them...
(In reply to David Rubio from comment #9) > Okay, I tried "force smoothest animations" and I still saw lag. So I ran > VSync tester and... I'm not crazy, everything is stuttering a LOT. > > I was like okay I might have to turn it a notch more. I will. It didn't make > a dent, everything is still absolutely not-having-it, and this is on > Wayland, both for Wayland and X11 clients, VSyncTester has the same effect > on either. > > Proof: https://i.imgur.com/P9kUMdz.png 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 Keep in mind this does happen on X11, but it's both not as incredibly bad, and it doesn't pause your mouse movement or stop rendering what you're typing, which is *incredibly* bad. (Also there should be an edit comment option ;w;)
@David The issues you've described sound unrelated to this bug report. Please file a bug report for the freezing issue as it's very difficult to track several bugs in a single bug report.
Created attachment 134801 [details] patch @Mojahed do animations stutter with this patch?
This patch increases input lag and the minimize/restore animation still doesn't look as smooth as I'd expect it. The animation speed slider in systemsettings also doesn't have any effect for me, while changing the value of AnimationDurationFactor in kwinrc does (is set to 0.5 for me). I wonder if I'm missing some additional -git version package.
There shouldn't be AnimationDurationFactor in kwinrc, remove that line.
Indeed the slider option now works again after removing that line. It's a bit weird though, as I deleted kwinrc after installing kwin-git, so it seems it was freshly created with that line included for whatever reason. I think the animations now look normal without the triple buffering patch. Not sure if the cubic animation curve selected in kwin-lowlatency didn't look better, but if it did it probably is entirely unrelated. Btw: The triple buffer patch also breaks proper vsync for me, lots of stutter at vsynctester.com while just sitting passively in front of the PC.
Does it also stutter when KWIN_USE_INTEL_SWAP_EVENT env var is set to 0?
Yes, scrolling in Firefox then still looks stuttery (like with lower fps, as if Firefox' vsync is hindered from correctly measuring refresh rate) and while the animation of vsynctester.com might not necessarily stutter, the data it measures and presents as a graph still looks bad too. But perhaps interesting side note: I then can set latency option to "force lowest latency" without having the input stutter mentioned in 431449. The input latency is very low too (like kwin-lowlatency with most aggressive setting).
(In reply to Vlad Zahorodnii from comment #14) > Created attachment 134801 [details] > patch > > @Mojahed do animations stutter with this patch? I test this patch, But animations lag not fix.
Created attachment 134829 [details] patch @Mojahed Very odd... I wonder if the timestamps actually come from CLOCK_MONOTONIC. Do animations lag with this patch?
This patch seems to completely fix issue 431449 on Xorg without negative side effects, I can now change to "force lowest latency" without any window moving skipping or stutter inside Firefox. :) Is a similar patch possible for KWin Wayland?
Created attachment 134845 [details] patch No, there is not. Now I wonder what presentation timestamps kwin receives via swap events. Can you run kwin_x11 --replace (in terminal) with the attached patch applied and post its output here?
Created attachment 134846 [details] kwin timestamp log
Attached the log (not sure if it sends a notification email without me posting another comment).
Yes, Bugzilla will send out a notification if you create an attachment in a bug report. Huh, that's weird. The presentation timestamp is a little bit in the future. It may potentially result stuttering. I wonder whether this is also the case on Wayland.
result in stuttering*
One would have to log verbosity into a file to get a similar log for Wayland, as there is no --replace equivalent, right?
With the patch in comment 23, the timestamps will be printed only on X11.
(In reply to Vlad Zahorodnii from comment #23) > Created attachment 134845 [details] > patch > > No, there is not. Now I wonder what presentation timestamps kwin receives > via swap events. > > Can you run kwin_x11 --replace (in terminal) with the attached patch applied > and post its output here? With this patch animations are smooth!
Created attachment 134853 [details] mojahed: kwin timestamp log my kwin log
(In reply to Vlad Zahorodnii from comment #23) > Created attachment 134845 [details] > patch > > No, there is not. Now I wonder what presentation timestamps kwin receives > via swap events. > > Can you run kwin_x11 --replace (in terminal) with the attached patch applied > and post its output here? Animations are way, way smoother now.
Created attachment 134854 [details] Attaching KWin timestamp log.
Created attachment 134855 [details] Last one was wrong, this one is the actual file. Oops. Sorry.
@Mojahed Can you also try with only this patch from another ticket (comment 18)? https://bugs.kde.org/show_bug.cgi?id=431449#c18 Looks like both issues might have the same root and that patch should fix the animations on Wayland as well.
Hmm, it looks like this bug and bug 431449 might be caused by the same issue after all. @Mojahed could you please check whether https://invent.kde.org/plasma/kwin/-/merge_requests/590 fixes this bug as well?
(In reply to Vlad Zahorodnii from comment #36) > Hmm, it looks like this bug and bug 431449 might be caused by the same issue > after all. @Mojahed could you please check whether > https://invent.kde.org/plasma/kwin/-/merge_requests/590 fixes this bug as > well? Yes, Animations smooth with only this patch. But with "Prefer lower latency" animations very stutter. Is this normal?
(In reply to Mojahed Yavazi from comment #37) > Yes, Animations smooth with only this patch. But with "Prefer lower latency" > animations very stutter. Is this normal? Yes, it's expected if your video card is not powerful enough, which is typically the case with intel gpus. With the "prefer lower latency" latency policy, the compositor tries to repaint screen as close as possible to the next vblank. If the screen is not repainted on time, you may see some stuttering. With the "prefer smoother animations" latency policy, the compositor will repaint the screen as further as possible from the next vblank, therefore the chances of missing the deadline are smaller than with the "prefer lower latency" policy. Anyway, thank you for the confirmation. :-)
Intel Gen9 GPUs are so slow that they also have performance issues with Webrender in Firefox, whereas Qualcomm SoC GPUs on Android often don't. It's quite astonishing.
(In reply to tempel.julian from comment #39) > Intel Gen9 GPUs are so slow that they also have performance issues with > Webrender in Firefox, whereas Qualcomm SoC GPUs on Android often don't. It's > quite astonishing. I can confirm this. It's pretty shameful.
Git commit b5a1eba2779b06715508365c6e2b86017151cef0 by Vlad Zahorodnii. Committed on 14/01/2021 at 18:45. Pushed by vladz into branch 'master'. Properly schedule repaints with premature presentation timestamps The last presentation timestamp might be in the future by a couple of hundred microseconds. This may break timestamp aligning code because it assumes that the last presentation timestamp is less or equal to the current time. In order to properly handle this case, we have to first compute the next expected presentation timestamp by advancing the last presentation timestamp by the amount of vblank interval. If that fails, we can safely resort to aligning timestamps. Related: bug 431449 M +5 -2 renderloop.cpp https://invent.kde.org/plasma/kwin/commit/b5a1eba2779b06715508365c6e2b86017151cef0
Definitely too late to comment, but the patch mentioned fixed it for me too. It's super smooth now.
(In reply to Vlad Zahorodnii from comment #38) > (In reply to Mojahed Yavazi from comment #37) > > Yes, Animations smooth with only this patch. But with "Prefer lower latency" > > animations very stutter. Is this normal? > > Yes, it's expected if your video card is not powerful enough, which is > typically the case with intel gpus. > > With the "prefer lower latency" latency policy, the compositor tries to > repaint screen as close as possible to the next vblank. If the screen is not > repainted on time, you may see some stuttering. > > With the "prefer smoother animations" latency policy, the compositor will > repaint the screen as further as possible from the next vblank, therefore > the chances of missing the deadline are smaller than with the "prefer lower > latency" policy. > > Anyway, thank you for the confirmation. :-) Why kwin with KWIN_USE_INTEL_SWAP_EVENT=1 and "Prefer lower latency" animations very stutter. But kwin with KWIN_USE_INTEL_SWAP_EVENT=0 and "Prefer lower latency" animations not stutter?
Maybe it takes some shortcuts then? Also with current git-master without patches, KWIN_USE_INTEL_SWAP_EVENT=0 breaks correct vsync for me in Firefox (stuttery scrolling etc.).
(In reply to tempel.julian from comment #44) > Maybe it takes some shortcuts then? Also with current git-master without > patches, KWIN_USE_INTEL_SWAP_EVENT=0 breaks correct vsync for me in Firefox > (stuttery scrolling etc.). Can you test KWIN_USE_INTEL_SWAP_EVENT=0 and MOZ_X11_EGL=1 ?
(In reply to Mojahed Yavazi from comment #45) > Can you test KWIN_USE_INTEL_SWAP_EVENT=0 and MOZ_X11_EGL=1 ? I always have that set for VAAPI. I'm with 85 beta, as it brought back real vsync for the EGL backend.
(In reply to Mojahed Yavazi from comment #43) > Why kwin with KWIN_USE_INTEL_SWAP_EVENT=1 and "Prefer lower latency" > animations very stutter. But kwin with KWIN_USE_INTEL_SWAP_EVENT=0 and > "Prefer lower latency" animations not stutter? With KWIN_USE_INTEL_SWAP_EVENT=0, kwin has no way knowing when a previously painted frame has actually been presented on the screen, so it tries to repaint the screen as fast as it receives vblank notifications. If some frame is running late, kwin will block and this will add a frame of latency. In other words, the latency policy that you've chosen in the compositor settings doesn't matter, this is equivalent to the "prefer smoother animations" option. An extra frame of latency is good for animations, but it's bad in terms of input latency. (In reply to tempel.julian from comment #46) > (In reply to Mojahed Yavazi from comment #45) > > Can you test KWIN_USE_INTEL_SWAP_EVENT=0 and MOZ_X11_EGL=1 ? > I always have that set for VAAPI. I'm with 85 beta, as it brought back real > vsync for the EGL backend. Huh, I'm very surprised that Mozilla devs found a way to get vsync notifications in the EGL backend. As far as I know, there is no any extension to get notified when a surface has been presented. The best option that you've got is to repaint the window when a timer expires. Other options include using the Present extension, but this doesn't really work on NVIDIA (we've tried it in kwin).
(In reply to Vlad Zahorodnii from comment #47) > Huh, I'm very surprised that Mozilla devs found a way to get vsync > notifications in the EGL backend. As far as I know, there is no any > extension to get notified when a surface has been presented. The best option > that you've got is to repaint the window when a timer expires. Other options > include using the Present extension, but this doesn't really work on NVIDIA > (we've tried it in kwin). For Mesa, this is done: https://bugzilla.mozilla.org/show_bug.cgi?id=1669275 It at least allows perfect vsync presentation timing on Xorg (apart from WebGL). In current Nightly builds also Wayland widget vsync source got extended to rasterization and WebGL. There is hope. :)
Removing keywords, so searching for them doesn't open this bug