Closed Bug 1740255 Opened 3 years ago Closed 3 years ago

widget.wayland.vsync doesn't detect display refresh rate correctly

Categories

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

x86_64
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1744896

People

(Reporter: tempel.julian, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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

Steps to reproduce:

Start a Plasma 5.23 Wayland session with a display refresh rate of 50Hz.
Force 50Hz via a custom EDID (kernel boot command drm.edid_firmware=...).

Actual results:

Firefox still renders at 60fps, causing stuttery scrolling etc. . about:support also lists 60fps as target. GPU accelerated Webrender with widget.wayland.vsync is used. The EDID only contains this single 50Hz resolution, Plasma's display settings list only 50Hz accordingly.

Expected results:

Firefox should render to smooth vsynced 50fps. It works in Chromium with Ozone Wayland or mpv Wayland.

It might be Intel specific, as I already had e.g. smooth vsyned 85fps Firefox Wayland running on an AMD GPU Wayland system.

Component: Untriaged → Widget: Gtk
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64

Robert, any idea?
Thanks.

Flags: needinfo?(tempel.julian)
Flags: needinfo?(tempel.julian) → needinfo?(robert.mader)
Blocks: wayland
Priority: -- → P3

walmartguy: can you post your about:support? Also, did you double check that you use the (still not default) Wayland backend (Window Protocol in about:support showing Wayland, not Xwayland)?

Flags: needinfo?(robert.mader) → needinfo?(tempel.julian)
Attached file aboutsupport.txt
Flags: needinfo?(tempel.julian)

Yes, it says Wayland.

Attachment #9252327 - Attachment description: aboutconfig.log → aboutsupport.txt
Attachment #9252327 - Attachment filename: aboutconfig.log → aboutsupport.txt
Attachment #9252327 - Attachment mime type: text/x-log → text/plain
Attached file 1080p 50Hz custom EDID

As it's a giant pain to create a custom EDID binary on Linux: Attaching an EDID containing 1920x1080 50Hz standard timings as the only resolution/refresh rate, created with CRU on Windows. It should safely work with any LCD 1080p display.

See Arch wiki for loading custom EDIDs (it's pretty straight-forward):
https://wiki.archlinux.org/title/kernel_mode_setting#Forcing_modes_and_EDID

Hopefully this is reproducible on any (Intel) system.

This still applies with current Nightly build (I think there was a similar issue that was resolved, so that didn't help in this case).

Looks like this build fixes it, auto scroll on (very) light sites is now smooth on that system with 50Hz: https://bugzilla.mozilla.org/show_bug.cgi?id=1744896#c68

However, it still reports 60fps in about:support, despite of the 50Hz it is correctly rendering at.

(In reply to walmartguy from comment #8)

Looks like this build fixes it, auto scroll on (very) light sites is now smooth on that system with 50Hz: https://bugzilla.mozilla.org/show_bug.cgi?id=1744896#c68

Thanks for confirming, marking as duplicate then!

However, it still reports 60fps in about:support, despite of the 50Hz it is correctly rendering at.

Changing that would require updating the about:support site to support per window refresh rates instead of only one global one (Wayland is the only platform supporting that ATM) - something too much GUI related for me to look into yet. But I totally agree that we should fix that at some point.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

Thanks, glad this is just cosmetic.
Well, now to the next level, which is if I can get smooth browser (Widevine) video playback on that painfully slow device. :)

(In reply to walmartguy from comment #10)

Well, now to the next level, which is if I can get smooth browser (Widevine) video playback on that painfully slow device. :)

You may want to look into bug 1713276!

(In reply to walmartguy from comment #10)

Well, now to the next level, which is if I can get smooth browser (Widevine) video playback on that painfully slow device. :)

Out of interest: what kind of device is that and do you have an idea what is the bottleneck? Because AFAIK it will be a rather hard task to make e.g. hardware video decoding work with Widevine (bug 1700815). However, there's a bunch of optimizations possible in other areas, depending on the hardware. At some point I hope to make bug 1711461 happen - maybe that's something you want to look into?

Thanks for making me aware of these tracker entries!

The device in question features a slow Intel Gemini Lake SoC with just two CPU cores and also very slow (and even more inefficient) GPU. Not even Chromium on Windows manages to play 1080p 60fps VP9 without any stutter (efficient video players like mpv can do it without issues though), so that would be quite some achievement. :)
However, I'd already be happy if 1080p/720p ~24fps video was fluid. It should be achievable, as SoC power consumption with software decoding is already below the 6W TDP limit (which is mercilessly enforced on Linux with this device after exceeding 60°C threshold) and bitrate spikes are hopefully low enough too.

With Chromium Wayland, there seems to be something wrong with at least Widevine, as it looks very stuttery vs. Windows (where it also just uses software decoding), despite vsynctester.com being smooth. I'll report back in case there is a similar oddity with Firefox Wayland.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: