1627863 - Wayland wrong framerate

Status: RESOLVED DUPLICATE of bug 1645528

(Core :: Graphics, defect, P3)

Description

[grmat]

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

Steps to reproduce:

Use Firefox on Wayland with a 144 Hz display

set/unset widget.wayland_vsync.enabled: no effect
enable/disable webrender: no effect

Developer edition 75.0b11: same issue

Actual results:

Firefox apparently renders at 60 FPS, animations, videos and scrolling are not rendered smoothly.

about:support shows "Target frame rate: 60"

testing sites1 also show 60 Hz.

Expected results:

Firefox should render at 144 Hz with vsync

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

[grmat]

I reverted the bot change, because the issue also appears with WebRender disabled.

Comment 3

[Robert Mader [:rmader]]

Mind sharing which compositor you use? And single or multi monitor?

Comment 4

[Robert Mader [:rmader]]

And when you're on it, could you verify other apps work as intended by running weston-simple-egl (part of the weston-demo package on fedora)?

In case you're running Gnome, please mind https://gitlab.gnome.org/GNOME/mutter/-/issues/3 - if you have multiple monitors and one is 60Hz and the other 144Hz, both will run at 60Hz. This is planned to get fixed in 3.38 / didn't make it to 3.36.

Comment 5

[grmat]

Tested on Sway (1.4) and kwin (KDE 5.18).

weston-simple-egl renders in the correct framerate.

Single monitor

Comment 6

[Robert Mader [:rmader]]

Just to be sure: you do run Firefox with MOZ_ENABLE_WAYLAND=1 and about:support does show Wayland as Window Protocol? Because in Xwayland Firefox is limited to a fake 60Hz.

Comment 7

[grmat]

Yes, of course.

Comment 8

[grmat]

Attachment: about:support info

attaching about:support info with

fresh profile
+widget.wayland_vsync.enabled
+layers.acceleration.force-enabled (tested this prior to webrender)
+gfx.webrender.all

Comment 9

[grmat]

Just tested on GNOME 3.36 as well, no change.

Comment 10

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 11

[Kenny Levinsen :kennylevinsen]

The refresh rate info is completely bogus here. It's just filled out with a constant value. I unfortunately don't have a 144Hz monitor to test with.

However, other bugs have observed that some things appear to run capped at 60fps (e.g., keyboard scrolling, auto scrolling), while others' run at full speed (mouse scrolling usually). Note, though, that rendering/compositing to screen is still driven only by frame callbacks when the option is enabled, so assuming no compositor bugs, that's happening at full screen refresh rate. The problem is likely that something updating content ends up capped.

I have some theories, but with no monitor to test it's all theoretical. If you want, I could probably make a pair of try builds with a few permutations to help isolate what area is to blame. Give me a heads up if you're up for it.

Comment 12

[grmat]

Several possibilities to confirm that Firefox doesn't update with more than 60 Hz, like Gallium HUD or enabling VESA Adaptive-Sync (AMD FreeSync) and the display's built-in HUD. So we don't have to trust my visual observation.

I'd gladly help testing, but I can't promise on response times. If you ping me directly, I try to answer quickly.

Comment 13

[Robert Mader [:rmader]]

Just confirmed that sites like https://www.vsynctester.com and https://www.testufo.com/ rely on requestAnimationFrame() (https://www.w3.org/TR/html52/webappapis.html#animation-frames), which again relies on nsRefreshDrivers. So marking this as a duplicate of bug 1645528