https://bugs.kde.org/show_bug.cgi?id=431509
--- Comment #47 from Vlad Zahorodnii <vlad.zahorod...@kde.org> --- (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). -- You are receiving this mail because: You are watching all bug changes.
