When compositing is enabled, drawing of frames is not happening in regular time intervals - it is stuttering. This is particularly noticeable - and becomes almost unbearable - during video playback. Reproducible: Always Steps to Reproduce: 1. Get my gltest program from https://www.ralfj.de/git/gltest.git (or some video with lots of scrolling) 2. Start "./glxtest -i 1" (or start the video) 3. Compare how it looks with compositing enabled, and disabled. Also try maximized and full-screen (F1 in gltest). Actual Results: With compositing disabled, the vertical bar moves smoothly, as it should. With compositing enabled, the bar starts to stutter, move irregularly. I am not sure if frames are dropped, or old frames are repeated. (Without compositing, of course, there's tearing if the window is just maximized, but that's expected.) Expected Results: It should be smooth, always. This is a bad regression compared to the previous version of kwin I used (from KDE 4.12 or so). I now have to disable compositing to watch videos. I tried both "Automatic" and "Full-scene repaint" as vsync settings, same behavior in both cases. I'm on Debian testing, with an Intel HD graphics card.
KWIN_USE_BUFFER_AGE=0 kwin_x11 --replace &
That doesn't look like it's changing anything.
Please provide the output of qdbus org.kde.KWin /KWin supportInformation then.
Created attachment 94677 [details] kwin support info
Can you please try whether you get the same behavior on UXA acceleration? --- /etc/X11/xorg.conf.d/20-intel.conf ---- Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" EndSection
That seems to make things much better in glxtest, and in watching a TV show. (The issue doesn't really show up when watching talks; not enough things move.) However, the intel Xorg driver hasn't been updated on my system since July 23rd. Doesn't this mean that SNA was used (without trouble) even before the update to KDE5? The only recent X-related update was updating xserver-xorg-core from 2:1.17.2-1 to 2:1.17.2-1.1, which according to the changelog was only about some man pages.
It could mean that the driver is knocked out by the massive amount of glx contexts in plasma 5. Can you log into a naked X11 server ("failsafe", only an xterm), run only kwin_x11 and your glxtest from there?
Rather ironically, the "failsafe" session fails. The log of sddm says "invalid session /usr/share/xsession/failsafe.desktop", and indeed there is no such file - or any file with that name anywhere in /usr, or in any package I could install. I don't know why SDDM even offers that session. (This is a bug I will report with the Debian packages.) I tried killing plasmashell (after disable UXA again), that did not change anything.
That doesn't cut it necessarily. I usually don't run plasmashell. When I did for testing and "accidentally" triggered the calendar view after some other popups (on an nvidia system) *every* GL (inc. KWin) client went south (completely, I had to restart X11) I've never seen such before :-(
As it's Intel hardware - same question as in every Intel specific bug report: does switching to xorg modesettings driver improve the situation?
There is stuttering in this app with OpenGL 2/3 and XRender and different VSync settings Plasma: 5.12.4 Apps: 17.12.4 Frameworks: 5.44.0 Qt: 5.10.1 Kernel: 4.14.32-1-MANJARO OS: Netrunner Rolling Video: Intel 4400 Driver: xf86-video-intel 1:2.99.917+823+gd9bf46e4-1 Screen: 1600x900
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
I have not noticed issues with video playback in a while. Using my test application, I did get a rather stuttering 20fps -- but then after restarting KWin, it is up to 60fps. So it seems like in principle KWin can handle this properly, but sometimes it might get into a degraded state? Not sure how to reproduce this though.
Thank you for your feedback. If it's hard to reproduce, it's usually even harder to fix :-( Not sure what can be done about this.
This bug was reported against an outdated version of KWin. We have made many changes since the. If the issue persists in newer versions can you reopen the bug report updating the version number.