[SOLVED] Tearing with Firefox when high RR [compositor off]

Wild Penguin · 2022-10-09 14:42:52

Hi!

Since recently(-ish) I seem to get tearing in Firefox. This happens in Youtube and when using Smooth Scroll and is quite distracting (otherwise I wouldn't be posting...). I haven't noticed any tearing in other applications, and also, this hasn't always (during/before last summer?) been the case. I certainly have been able to watch YT videos without tearing before in Firefox.

Now, searching with "firefox tearing" brings loads of hits, some of which are more recent and some are really, really old issues (here and in Reddit) - which points to tearing being a re-curring problem on Firefox (and seems like in Windows, too?). I haven't found anything relevant to my case, but it is certainly possible someone has the same issue - it's just difficult to find among all the hits.

I noticed I don't get tearing if I set the refresh rate to 50Hz. But I'd rather keep it at 100Hz (didn't try 60Hz). FWIW I usually keep VRR (Freesync) enabled, but disabling it, I still get tearing.

Important details (I can think of, please ask more in case you can think of something relevant information missing):

X.org
KDE Plasma
amdgpu (RX Vega 64)
100Hz refresh rate (none at 50Hz; didn't try 60Hz); 3440x1440 (though I doubt resolution is important)
layers.acceleration.force-enabled = true in about:config (set as this was suggested, but this has no effect).
Currently using -zen branch of the Kernel, but I've had this on the default branch, too
xrandr --prop lists TearFree as "auto", setting it "on" has no effect

Not sure what other information might be relevant / where to start troubleshooting. Any ideas are welcome! Especially getting YT to be tear-free would be nice.

For scrolling, disabling smooth scroll is suggested in the Wiki - but that is certainly a workaround, not a fix (and will do nothing to video playback).

EDIT: I noticed I do not get tearing if I set compositor on. But I get tearing if I set compositor off. The reason I have not noticed this before, is that previously games run well even with compositor on, but recently I've noticed some games don't like it (frame rate is approximately halved) - so I've started to disable it. And hence: noticed the tearing in Firefox. This is surprising, since usually one would expect to have less tearing etc. problems with compositor disabled. For the time being, I'll start setting compositing (desktop effects i.e. CTRL+ALT+F12 per default) on in KDE Plasma when not running a game.

Cheers!

p.s.:

$ inxi -SG
System:    Host: ArkkiVille Kernel: 5.19.13-zen1-1-zen x86_64 bits: 64 Desktop: KDE Plasma 5.25.5 Distro: Arch Linux 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] driver: amdgpu v: kernel 
           Display: x11 server: X.Org 21.1.4 driver: amdgpu tty: N/A 
           OpenGL: renderer: AMD Radeon RX Vega (vega10 LLVM 14.0.6 DRM 3.47 5.19.13-zen1-1-zen) v: 4.6 Mesa 22.1.7

Last edited by Wild Penguin (2022-10-14 14:38:23)

Trilby · 2022-10-09 15:55:56

I don't have anything to offer for good solutions, but wanted to correct the following:

Wild Penguin wrote:

This is surprising, since usually one would expect to have less tearing etc. problems with compositor disabled.

You've got that bass ackwards: these sorts of tearing issues are the primary reason for compositors to exist as that's the problem they solve. It is, in fact, impossible to get screen tearing with a functional compositor.

A compositor may use more computational resources which may be why the games frame rates are lower. But also check the frame rate of the compositor and your actual monitor. Having games output more frames than are actually displayed is pointless - it may feel nice to see your game reporting that it's outputing a huge amount of frames, but for that to actually have any benefit, the monitor needs to be able to keep up. A compositor will sync the monitor and game refresh rates, so it's possible that this is why you get lower frame rates from the games (and in such a case, any perceived difference would be purely placebo effect or imagined). When you say game frame rates are halved with a compositor running, what do they change from / to (i.e., actual values)?

Last edited by Trilby (2022-10-09 23:00:18)

V1del · 2022-10-09 18:45:38

Steam games normally suspend the compositor by default and reenable it when you quit, that is what recently broke somewhere in steam. All your other observations are expected as Trilby notes. FWIW from what I've seen there's no good way to avoid the compositing perf hit while gaming with Kwin safe for a Wayland session

seth · 2022-10-09 19:22:03

Display: x11 server: X.Org 21.1.4 driver: amdgpu tty: N/A

Did you "recently(-ish)" switch to amdgpu because of issues w/ the modesetting driver?
https://wiki.archlinux.org/title/AMDGPU … _rendering

Though compositor or not, if the client syncs to the output, you should™ not get any tearing.
Is the tearline in a static position or all over the place?

Wild Penguin · 2022-10-14 14:37:42

Thanks for all the replies!

Commenting inline:

Trilby wrote:

You've got that bass ackwards: these sorts of tearing issues are the primary reason for compositors to exist as that's the problem they solve. It is, in fact, impossible to get screen tearing with a functional compositor.

You are right, and I agree, now that I think of it!

Trilby wrote:

A compositor may use more computational resources which may be why the games frame rates are lower. But also check the frame rate of the compositor and your actual monitor. Having games output more frames than are actually displayed is pointless - it may feel nice to see your game reporting that it's outputing a huge amount of frames, but for that to actually have any benefit, the monitor needs to be able to keep up. A compositor will sync the monitor and game refresh rates, so it's possible that this is why you get lower frame rates from the games (and in such a case, any perceived difference would be purely placebo effect or imagined). When you say game frame rates are halved with a compositor running, what do they change from / to (i.e., actual values)?

The games still report high frame rate (for example, 100Hz while it feels like 50Hz or lower). My monitor still reports 100Hz (same result with FreeSync on or off). I have no idea how to increase the frame rate of the compositor. (and of course, FreeSync shouldn't work unless the game has exclusive fullscreen -> compositor can not work at the same time, at least)

However, I made a curious observation: if I play in a window, the frame rate is smooth(er), but obviously without exclusive fullscreen and no VRR. When I start in a fullscreen, the frame rate is c*p (consistently, game reporting high) - but desktop effects are not disabled! So, it seems the game thinks it has exclusive fullscreen, while it doesn't, and things break down because of this. I checked this by setting a game borderless-fullscreen (which is essentially a window without decorations taking up the whole screen) -> frame rate is smooth.

A part of the key was here:

V1del wrote:

Steam games normally suspend the compositor by default and reenable it when you quit, that is what recently broke somewhere in steam. All your other observations are expected as Trilby notes. FWIW from what I've seen there's no good way to avoid the compositing perf hit while gaming with Kwin safe for a Wayland session

This is exactly what is happening - i.e. games don't suspend compositor (for some reason) when starting anymore - and this got me confused, as I've not given a much though for it previously. Usually I just start a game - and very seldom switch to another app when gaming. When I finish, the effects have been re-enabled (as I recall it). But this (automatic disabling) does not happen anymore! I also noticed that if I toggle fullscreen off and back, the desktop effects are disabled automatically - the problem is just when starting a game (several games I've had time to try/play with)!

In summary:

automatic disabling of compositor broke somehow, when starting a fullscreen application/game (in case someone is wondering: the setting for this "permission" is enabled in KDE Plasma compositor settings).
I strongly believe Firefox has always had tearing, in case compositor is off. Since I previously had the automatic disabling (and re-enabling) working, I've just never noticed before.

Cheers!

p.s. the games I've been playing recently are using wine / Proton. I could test later if the same issue persists with native games, and with non-proton Wine....

EDIT: slight formatting, added TYPOs...

Last edited by Wild Penguin (2022-10-14 14:43:29)

Arch Linux

#1 2022-10-09 14:42:52

[SOLVED] Tearing with Firefox when high RR [compositor off]

#2 2022-10-09 15:55:56

Re: [SOLVED] Tearing with Firefox when high RR [compositor off]

#3 2022-10-09 18:45:38

Re: [SOLVED] Tearing with Firefox when high RR [compositor off]

#4 2022-10-09 19:22:03

Re: [SOLVED] Tearing with Firefox when high RR [compositor off]

#5 2022-10-14 14:37:42

Re: [SOLVED] Tearing with Firefox when high RR [compositor off]

Board footer