Open Bug 1630631 Opened 4 years ago Updated 4 years ago

Firefox freezes for a while when resetting layout.frame_rate pref to default

Categories

(Core :: Graphics, defect, P3)

Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr68 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix

People

(Reporter: atrif, Unassigned, NeedInfo)

References

Details

(Keywords: regression)

Affected versions

  • 77.0a1 (20200413034542)
  • 76.0b5 (20200415234430)

Affected platforms

  • Windows 10 x64
  • Ubuntu 18.04
  • macOS 10.12

Steps to reproduce

  1. Open Firefox and go to about:config.
  2. Set layout.frame_rate to 120.
  3. Click the Reset button to restore defaults.

Expected result

  • Default state is restored as expected.

Actual result

  • Firefox freezes for a while.

Regression Range

  • I will search for one ASAP if there is one.

Notes

  • Firefox 75.0 (20200403170909) is marked as unaffected because it’s crashing when changing layout.frame_rate pref due to bug 1614212.
Has Regression Range: --- → no
Has STR: --- → yes

I suspect this is a dupe of bug 1519127. :sotaro, does that look right?

Component: Widget → Graphics
Flags: needinfo?(sotaro.ikeda.g)
Priority: -- → P3

<Slightly Related Consideration>

(Not sure if this warrants a separate bug tracking entry)

One thing I would like to make sure is that layout.frame_rate is compatible with G-SYNC and FreeSync (aka VRR - Variable Refresh Rate).

VRR support is super-easy in theory, the display simply slaves to software -- monitor refreshes immediately upon Present() or glxxSwapBuffers() -- as seen in this diagram: https://blurbusters.com/wp-content/uploads/2018/04/Present_GSYNC_VSYNC_ON-640x690.png
Basically, the monitor slaves to the software present API, rather than its own fixed refresh.

So basically instead of presenting framebuffers to a synchronous refresh rate, framebuffers can be presented by timer driven by layout.frame_rate and VRR will simply automatically work. But there's ONE weak link problem, which I need help with. Hopefully it's just a one line fix, while you fix this bug.

I have created motion tests at www.testufo.com and we've been trying to add a VRR mode to them.

In the long term, we'd like software to have real-time control over layout.frame_rate since VRR monitors are slaving to refresh cycles (The monitor waits for frame presentation before refreshing). So in full screen mode, the layout.frame_rate should in theory automatically switch to VRR mode.

VRR Testing with browsers

For now, NVIDIA has temporarily blacklisted firefox.exe from VRR mode, but if I rename firefox.exe into another name like marshmallow.exe or firefox-vrr.exe and run it, I am able to force VRR into FireFox in full screen mode using NVIDIA Control Panel:

  • Rename FireFox executable (temporarily)
  • Launch NVIDIA Control Panel
  • Select "Display" -> Set Up G-SYNC -> Enable G-SYNC -> both windowed and full screen
  • Select "3D Settings" -> Manage 3D Settings
  • Select Program Settings -> Click Add -> Select custom FireFox Executable
  • Select Program Settings -> Monitor Technology -> G-SYNC
  • Configure FireFox layout.frame_rate to a lower number
  • Launch https://www.testufo.com/photo

EXPECTED: TestUFO scroll smoothly. layout.frame_rate = 57 should be automatically setting monitor to 57Hz (since refresh rate is controlled by Present() frequency)

PROBLEM: However, TestUFO still stutters -- it seems like it is not synchronizing Present() or redraws to the layout.frame_rate timer.

In the long term, I'd like to help incubate JavaScript control over the desired frame rate (e.g. a JavaScript method of controlling layout.frame_rate) so that browsers can become variable-refresh compatible as seen at Adding Variable Refresh Rate Support to HTML Standard. But before a full standardization occurs, what I need is a way to be able to feasibly incubate variable refresh support in web browsers, as follows.

I have partnered with NVIDIA for some Blur Busters / TestUFO projects and have some pull to whitelisting web browsers for VRR eventually. But the initial developer incubation test for VRR

VRR Incubation Feature via layout.frame_rate

  • DONE - The ability to enable VRR mode in full screen mode (DONE: Rename browser executable for now, until I convince NVIDIA
  • DONE - The ability to manually configure a browser to fixed frame rate initially (DONE: layout.frame_rate)
  • PROBLEM - The browser presents frame buffer on the layout.frame_rate timer rather than separate fixed-Hz timer.

Possible workaround: Whenever layout.frame_rate is not default (match Hz), make frame presentation sync to the layout.frame_rate timer while in full screen mode.

One of you (with a FreeSync monitor or G-SYNC monitor) needs to test this. Make sure to set a layout.frame_rate at a frame rate within the refresh rate range. Many new DELL desktop office monitors now can do FreeSync at 48Hz-75Hz, so you could test "layout.frame_rate = 55" to emulate a 55Hz monitor.

</Slightly Related Consideration>

Made a regression check for this and I got these results:
Last good revision: d02d14a3dd6e172c4cc8efb5c749752d3893fc90 (2018-12-14)
First bad revision: 8f91fb1acea5ed5585a8502599e51adfc1618de2 (2018-12-15)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d02d14a3dd6e172c4cc8efb5c749752d3893fc90&tochange=8f91fb1acea5ed5585a8502599e51adfc1618de2
Possible regressor: Bug 1503339.

(In reply to Alexandru Trif, QA [:atrif] from comment #0)

Notes

  • Firefox 75.0 (20200403170909) is marked as unaffected because it’s crashing when changing layout.frame_rate pref due to bug 1614212.

I think we are safe here to mark 75 as affected too and this is most probably a dupe of bug 1519127.

Has Regression Range: no → yes

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.)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.