1629140 - Wayland: Enable frame callback based VsyncSource by default

Status: RESOLVED FIXED

(Core :: Graphics, enhancement, P3)

Description

[Robert Mader [:rmader]]

Using the frame callback based VsyncSource (widget.wayland_vsync.enabled: true), apart from bringing a better experience on non-60hz monitors, offers significant power savings in in scenarios where FF is not visible. On Gnome Shell this includes being hidden by other windows (new in 3.36) or being on a not focused workspace.

Given that the feature has baked for a number of cycles already and previously found bugs should be fixed / shipped by now, lets enable it by default to get more feedback in nightly/beta. If it causes problems we can still disable it in the release channel.

STR for the previously mentioned powersavings on GS 3.36:

• enable widget.wayland_vsync.enabled
• open a taxing website like https://www.vsynctester.com/
• open gnome-terminal and run htop
• maximize and unmaximize the terminal in front of firefox and compare the cpu usage
• compare to widget.wayland_vsync.enabled: false

Comment 1

[Robert Mader [:rmader]]

Attachment: Bug 1629140 - Enable frame callback based VsyncSource by default. r=stransky

Comment 2

[Brandon Watkins]

I've had this enabled for a while, the only issue I've seen is this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1619246

I can confirm that this is still an issue in nightly 77

Comment 3

[David Heidelberg [:okias]]

Dell XPS 9350, Intel -- Mesa Intel(R) HD Graphics 520 (SKL GT2)
native Firefox 75 (gentoo) - no change after setting vsync
flatpak 73_beta3 - no change after setting vsync.

Running webrender on both.

Comment 4

[Kenny Levinsen :kennylevinsen]

:okias Please open a separate issue. In that issue, specify what compositor you use, verification that you are indeed running in Wayland mode, as well as reproduction and expected behavior of the problem you see.

That issue can then be made a blocker if deemed necessary, but we can't track issues in comments.

Comment 5

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 6

[grmat]

offers significant power savings in in scenarios where FF is not visible. On Gnome Shell this includes being hidden by other windows (new in 3.36) or being on a not focused workspace

The same should be true for wlroots/sway. Tested with Firefox developer edition 76.0b5 and wlroots/sway git master for VESA adaptive sync support:

1. enable adaptive sync and idle -> screen refreshes at minimum rate (40 Hz)
2. open Firefox, open a page with animation/video -> screen refreshes at video rate (e.g. 60 Hz)
3. move to another workspace, FF is invisible now but the screen still refreshes at the higher refresh rate

This issue was also described in https://github.com/swaywm/sway/issues/5076#issuecomment-599133439

With widget.wayland_vsync.enabled, the screen refreshes with the minimal possible refresh rate again once FF is invisble (on another workspace or covered by a fullscreen window), as it would be expected.

Comment 7

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

I'll look at it this week.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d412b7923e10
Enable frame callback based VsyncSource by default. r=stransky

Comment 9

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/d412b7923e10

Comment 10

[Robert Mader [:rmader]]

Reopening as it got disabled again in bug 1632519. Lets properly fix the bugs and try again.

Comment 11

[Robert Mader [:rmader]]

Unfortunately the test infrastructure still uses Ubuntu 18.04 (or even 16.04) which in the Wayland world is quite old and has many known bugs. I opened https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1570 / https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1905330 which will be needed for the vsyncsource. Alternatively we could force-off the pref for testing - but that would be somewhat hacky.

Comment 12

[Robert Mader [:rmader]]

Martin, as soon as bug 1645528 lands I'd like to reland this. Unfortunately that may get into the way of you testing infrastructure work (see comment above). Would it be easy for you to disable the pref in the tests?

Comment 13

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

(In reply to Robert Mader [:rmader] from comment #12)

Martin, as soon as bug 1645528 lands I'd like to reland this. Unfortunately that may get into the way of you testing infrastructure work (see comment above). Would it be easy for you to disable the pref in the tests?

The testsuite it broken anyway so don't hold your horses just because of it.

Comment 14

[Robert Mader [:rmader]]

Attachment: Bug 1629140 - Enable frame callback based VsyncSource by default. r=stransky

The issues from last time seem to be fixed, lets try again.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9658708ceaea
Enable frame callback based VsyncSource by default. r=stransky

Comment 16

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/9658708ceaea

Comment 17

[Robert Mader [:rmader]]

For the record: with regards to bug 1655282 comment 10 I expect a slightly higher crash rate with Webrender enabled now, although nothing completely new - however, if the problem pointed out there is indeed the culprit, we should be able to come up with a fix in time before 85 enters beta.

Comment 18

[David Gow]

I think this is causing some pretty annoying problems under KDE/KWin 5.20.3, on a Mesa 20.2.3 / Intel Kabylake setup (openSUSE Tumbleweed). For the last couple of nightly builds, basically, the window isn't updating most of the time. Sometimes there'll be bursts of animation, and sometimes the screen will stay stuck on one frame for a while. It works perfectly if I force it to run under XWayland with GDK_BACKEND=x11, so this is definitely a Wayland issue. It seems consistent with the idea that new frames are not being sent to the wayland compositor (or are being discarded or unused there), which could be because a vsync callback or something isn't being triggered.

I think I've successfully traced it back to this vsync setting: disabling it fixes the issue, and a bisect with mozregression-gui (which I think I was using correctly) showed the commit above (9658708ceaea) which enabled it by default. (This was with webrender force-enabled.)

(Please let me know if you want more info, or if this sounds like it is worth filing a separate bug either here or with KDE for. In the meantime, it may be worth reconsidering making this a default.)

Comment 19

[Robert Mader [:rmader]]

(In reply to David Gow from comment #18)

...

Yes, this is a known issue in KWin, see bug 1616894 and https://bugs.kde.org/show_bug.cgi?id=428499

As the Wayland backend is not yet activated by default, IMO we should not implement any detection for that in FF and hope KWin devs fix the issue.

Comment 20

[Julien Cristau [:jcristau]]

Bug 1645528 was backed out of beta 85, so I backed this one out as well to be safe:
https://hg.mozilla.org/releases/mozilla-beta/rev/7ecf63ed28977eb9c4decc9f09fa84f6527a0a8e

Comment 21

[Alexey.Rusakov]

(In reply to Robert Mader [:rmader] from comment #19)

(In reply to David Gow from comment #18)

...

Yes, this is a known issue in KWin

I encountered it using Gnome Shell too, see bug 1700005.