Closed Bug 1519127 Opened 6 years ago Closed 2 months ago

Switching back to hardware vsync source causes visual freeze

Categories

(Core :: Graphics, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox66 --- affected

People

(Reporter: Gijs, Unassigned)

References

Details

I don't really understand why this happens, but it does, so filing.

STR:

  1. open new profile on mac/windows (haven't tested linux, wouldn't be surprised if it happened there too)
  2. open about:config
  3. toggle layout.frame_rate to some positive number like 30 or 60.
    (now responsiveness is fine, you can see when hovering over the column headers or various other browser elements)
  4. right click it, click 'reset'

ER:
responsiveness should still be fine

AR:
no painting (or something?) until you switch tabs, resize the window, or do something else that somehow gives the whole thing a proverbial kick to "make it work" again.

From the profile, it seems the compositor and painting stops: https://perfht.ml/2QC8I5G .

:kats, do these symptoms give you any clue as to what's going on here?

Flags: needinfo?(kats)
Blocks: 1503339

Offhand I don't have any theories as to why this might be.

Flags: needinfo?(kats)

I confirmed the problem on Win10 and linux.

When VsyncSource::Display is relplaced by new one in gfxPlatform::ReInitFrameRate(), new display did not enable vsync since VsyncSource::Display::UpdateVsyncStatus() did not called.

Priority: -- → P3

(In reply to Sotaro Ikeda [:sotaro] from comment #3)

When VsyncSource::Display is relplaced by new one in gfxPlatform::ReInitFrameRate(), new display did not enable vsync since VsyncSource::Display::UpdateVsyncStatus() did not called.

Right, but even calling it from MoveListenersToNewSource (and making sure we're no longer in the lock) doesn't seem to be enough, from what I can tell from local testing. I suspect this is because when we hit https://searchfox.org/mozilla-central/rev/39265dd58298c40bed029617ad408bf806cce761/gfx/thebes/VsyncSource.cpp#131-132 , there might not be compositor listeners, and mRefreshTimerNeedsVsync is initialized to false. The widget code in VsyncDispatcher that normally calls into here and can enable/disable vsync doesn't seem to expose a way of doing this publicly. Not sure if it'd be kosher to add one, or if there's some other way of accomplishing this that would be preferable?

Flags: needinfo?(sotaro.ikeda.g)
Severity: normal → S3

On my Win11x64 machine, I could repro this bug on a build from the date of comment #0.
I do not repro this on the latest Nightly.
:Gijs, can you still repro this?

Flags: needinfo?(gijskruitbosch+bugs)

Thanks for flagging, I agree this seems to work now.

Status: NEW → RESOLVED
Closed: 2 months ago
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(gijskruitbosch+bugs)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.