Switching back to hardware vsync source causes visual freeze
Categories
(Core :: Graphics, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox66 | --- | affected |
People
(Reporter: Gijs, Unassigned)
References
Details
I don't really understand why this happens, but it does, so filing.
STR:
- open new profile on mac/windows (haven't tested linux, wouldn't be surprised if it happened there too)
- open about:config
- 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) - 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?
Comment 1•6 years ago
|
||
Offhand I don't have any theories as to why this might be.
Comment 2•6 years ago
|
||
I confirmed the problem on Win10 and linux.
Comment 3•6 years ago
|
||
When VsyncSource::Display is relplaced by new one in gfxPlatform::ReInitFrameRate(), new display did not enable vsync since VsyncSource::Display::UpdateVsyncStatus() did not called.
Updated•6 years ago
|
Reporter | ||
Comment 4•6 years ago
|
||
(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?
Updated•2 years ago
|
Comment 5•2 months ago
|
||
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?
Reporter | ||
Comment 6•2 months ago
|
||
Thanks for flagging, I agree this seems to work now.
Description
•