1684709 - Firefox window on Xorg doesn't trigger page flipping in fullscreen, causing tearing

Status: RESOLVED WONTFIX

(Core :: Widget: Gtk, defect, P5)

Description

[walmartguy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Run an Xorg graphical environment that allows to deliberately suspend compositing (e.g. KDE Plasma or Xfce) and suspend compositing.
Make sure Webrender is enabled in Firefox and play this video in fullscreen: https://www.youtube.com/watch?v=_gBBz7IMz1Y

Actual results:

Video tears, as Firefox doesn't trigger page flipping despite of it being run in fullscreen mode.

Expected results:

There should be no tearing when Firefox is run in fullscreen mode, as it should trigger page flipping like e.g. mpv does.

Use cases: Very slow devices like Gemini Lake, additional window compositing comes with a substantial performance penalty for them. It also unnecessarily decreases battery life. There is tear free mode via xf86 Xorg drivers available as an alternative, but it e.g. is notoriously broken on Intel.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Robert Mader [:rmader]]

I'm afraid this is something we won't do. It would:

• require significant work in the frame scheduling code
• likely trigger bugs in multi-window situations (if not even more work is invested)

AFAICS the best way forward here is using Wayland. Wayland compositors can use direct scanout (read: unredirect) without the tearing problems, providing the benefits from both worlds. Unfortunately Mutter, KDE and Sway are all not quite there yet, but Weston already does this in many situations. So, well, better invest the work in future technology instead of legacy/dead ones.

There is tear free mode via xf86 Xorg drivers available as an alternative, but it e.g. is notoriously broken on Intel.

This option is AFAIK just a hacky "compositor in the driver" workaround. So it has the same overhead as a X11 compositor.

Comment 3

[Robert Mader [:rmader]]

P.S.: I can especially recommend to look at the Wayland compositor integration work (bug 1617498). It still needs some polishing regarding CPU overhead, but it's an explicit goal to improve performance on low end devices - i.e. the raspberry pi, phones or older ones. I sometimes test it on an old Thinkpad T400 and it does quite well :)

Comment 4

[walmartguy]

Well, if you say it'd require quite some efforts to invest, I have no reason to doubt that. And since you're time is sparse and you work on lots of other great things, how can I argue against that. :)

TearFree generally works great with xf86-video-amdgpu (Thanks to Michel Dänzer!), it is basically ~free on an RX 560, also when the GPU is maxed out by a game at the same time. Situation with xf86-video-intel is unfortunate, I think TearFree would still be much cheaper than a full blown GL compositor if it was properly fixed.

Wayland compositor integration sounds intriguing. The Wayland backend already beats up Windows D3D11 ANGLE on vsynctester.com on a slow Gemini Lake GPU even without it.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Won't fix based on comment 2, not so much the work aspect (we'll take patches), but the issue with regressions.