Bug 383023

Summary:	Firefox and mpv stutter with 75Hz on Intel Skylake IGP
Product:	[Plasma] kwin	Reporter:	tempel.julian
Component:	compositing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kde.org, univerz
Priority:	NOR
Version:	5.13.4
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	qdbus org.kde.KWin /KWin supportInformation for 60Hz resolution qdbus org.kde.KWin /KWin supportInformation for 75Hz resolution

Description tempel.julian 2017-08-01 21:26:07 UTC

Kernel 4.12, Mesa 17.1, Plasma 5.10.3 (5.10.4 wasn't available at the time of testing, but can retry with this version), Firefox 54, mpv 0.25.0 (was the current version at that time)

I got an old LCD 1280x1024 display connected via DVI which supports both 60Hz and 75Hz.
When I set it to 75Hz, automatic scrolling in Firefox (can be enabled in the options for 3rd mouse button, full OGL acceleration via about:config) is stuttery. It looks very much like it was scrolling with 60fps, which naturally looks stuttery at 75Hz display refreshrate. This stuttering disappears when I set the display to 60Hz.
This is not an issue of Firefox but Plasma's compositor since the stuttering with 75Hz disappears when I disable Plasma's compositor. It runs with totally fluid 75fps @ 75Hz then.

mpv also suffers some stuttering, even with 60Hz and 60fps video. This issue disappears as well with disabled Plasma compositing.

I also tried a custom edid file for the display which always forces it to 75Hz (60Hz aren't reported as available then), that unfortunately didn't help.
Plasma's compositing of moving windows looks totally smooth to me on the contrary (also without the custom edid and normally selected 75Hz in Plasma System Settings), so it "only" seems to be a problem with the content of windows, not the windows themselves (but I'm just guessing).

Now the thing is: When I enforce KWIN_USE_INTEL_SWAP_EVENT, every mentioned problem disappears. Both Firefox and mpv are absolutely smooth then at any refreshrate, and so is KWin compositing still in general.
Unfotunately, the lock-up bug described on the environment variables help site still exists. This seems to usually hapen when the compositing gets turned off, so probably simply not allowing applications to turn off compositing could work well enough.

However, it of course would be better if everything worked right ootb and without drawbacks.

Comment 1 Martin Flöser 2017-08-02 04:22:25 UTC

Please provide the output of
qdbus org.kde.KWin /KWin supportInformation
for both refresh rates.

Comment 2 tempel.julian 2017-08-02 17:26:48 UTC

Created attachment 107042 [details]
qdbus org.kde.KWin /KWin supportInformation for 60Hz resolution

Comment 3 tempel.julian 2017-08-02 17:27:10 UTC

Created attachment 107043 [details]
qdbus org.kde.KWin /KWin supportInformation for 75Hz resolution

Comment 4 Martin Flöser 2017-08-02 19:23:41 UTC

Given the output it could be that the refresh rate for repainting does not get recalculated when screen refresh rate changes.

Comment 5 tempel.julian 2017-08-02 19:40:31 UTC

I restarted the whole system after changing the refreshrates to be extra sure. :)

Comment 6 Martin Flöser 2017-08-02 20:01:57 UTC

Please change the settings in Tearing prevention. You are using Re-use screen content which shows a warning that it causes performance issues with your hardware. Best use automatic.

Comment 7 tempel.julian 2017-08-02 21:33:36 UTC

Happens with automatic too. I can boot a Kubuntu 17.04 live disc and experience the issue ootb.

Comment 8 tempel.julian 2018-02-23 20:55:44 UTC

Someone found out that setting KWIN_TRIPLE_BUFFER=0 solves the issue on both Intel and Radeon (Mesa):
https://forum.kde.org/viewtopic.php?f=111&t=138262&p=379117#p379117
I got a Radeon RX 560 now and I can confirm that it indeed does the trick.

It also solves the problem of stuttery compositing for the first few seconds after compositing gets enabled (is this some kind of TB probing?).

So, it seems to me that TB=0 should be the default for Mesa drivers so that the user wouldn't have to investigate regarding this problem with an environment variable tweak.

PS: OGL 3.1 and Re-use screen content setting work without issues with TB=0.

Comment 9 tempel.julian 2018-03-09 12:17:13 UTC

Ok, there is still a very minor stuttering left when scrolling with the mousewheel (not autoscrolling).
Compton for life...

Comment 10 tempel.julian 2018-08-22 14:26:49 UTC

Would it be possible that this gets reviewed again?
Let's keep mpv out of it as there seem to be other Intel issues with it.

But Firefox with OpenGL rendering should scroll absolutely stutter free, which is not the case with KWin X11 compositing on neither Radeon or Intel graphics.

It seems there is a detection to triple buffering, as changing the option to 0 already helps a lot (but also increases additional altency).

Firefox scrolling in a Gnome X11 session is stutter free and Mutter/Gnome Shell also has low input latency at the same time.

Not even e.g. moving Dolphin's window is stutter free with KWin X11 and free drivers.

Comment 11 tempel.julian 2018-08-22 14:28:03 UTC

*wanted to say "connection" and not "detection".

Comment 12 tempel.julian 2018-08-24 20:34:12 UTC

Closing, as continued here:
https://bugs.kde.org/show_bug.cgi?id=397850

Comment 13 kde.org 2021-11-06 21:37:47 UTC

This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?

Comment 14 tempel.julian 2021-11-07 17:33:08 UTC

KWin compositing is fine nowadays. :)