Improve how VsyncDispatchers swap out their VsyncSource
Categories
(Core :: Graphics, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox102 | --- | fixed |
People
(Reporter: mstange, Assigned: mstange)
References
(Blocks 1 open bug)
Details
Attachments
(16 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
At the moment, if you change the layout.frame_rate pref, we create a hardware or software VsyncSource, and then tell the old VsyncSource's RefreshDriverVsyncDispatcher to swap out its vsync source. The way this works is currently rather brittle, and the switching doesn't happen everywhere it should.
For bug 1759232 I want to uses a similar mechanism when a window moves across screens: On macOS there will eventually be one VsyncDispatcher per window and one VsyncSource per screen. So the VsyncDispatcher would switch out its VsyncSource when the window moves to a different screen. (At the moment there is one global VsyncDispatcher and one global VsyncSource on macOS.)
As part of this refactoring, I'm going to rename RefreshDriverVsyncDispatcher to VsyncDispatcher and remove many direct uses of VsyncSource and replace those uses with uses of VsyncDispatcher.
| Assignee | ||
Comment 1•4 years ago
|
||
RefreshTimerVsyncDispatcher manages a lot more than just the
RefreshDriverVsyncTimer these days.
Depends on D144362
| Assignee | ||
Comment 2•4 years ago
|
||
Depends on D144363
| Assignee | ||
Comment 3•4 years ago
|
||
Depends on D144364
| Assignee | ||
Comment 4•4 years ago
|
||
This makes it so that the VsyncSource doesn't need to keep track of the compositor vsync dispatchers.
And the moving-between-sources logic needs to be handled only for the VsyncDispatcher.
Once we have one VsyncDispatcher per window, we can probably eliminate CompositorVsyncDispatcher.
Depends on D144365
| Assignee | ||
Comment 5•4 years ago
|
||
Depends on D144366
| Assignee | ||
Comment 6•4 years ago
|
||
Now gfxPlatform and gfxPlatform::mVsyncSource have shared ownership of the VsyncDispatcher.
This is in preparation for reversing the ownership relationship between VsyncSource and VsyncDispatcher.
Depends on D144367
| Assignee | ||
Comment 7•4 years ago
|
||
Depends on D144368
| Assignee | ||
Comment 8•4 years ago
|
||
This doesn't change much; VsyncParent was already only using mVsyncSource
to obtain the VsyncDispatcher. (And to get the vsync rate, which it can
now get directly from the dispatcher.)
Depends on D144369
| Assignee | ||
Comment 9•4 years ago
|
||
Main thread observers (previously "generic" observers) are only used
by Windows touchpad scrolling so far.
Depends on D144370
| Assignee | ||
Comment 10•4 years ago
|
||
Depends on D144371
| Assignee | ||
Comment 11•4 years ago
|
||
This draws a clearer line between hardware vsync and software vsync.
Depends on D144372
| Assignee | ||
Comment 12•4 years ago
|
||
All users of nsIWidget::GetVsyncSource just want the dispatcher anyway.
Getting the dispatcher directly from the widget will allow us to remove VsyncSource::GetVsyncDispatcher.
Depends on D144373
| Assignee | ||
Comment 13•4 years ago
|
||
This makes vsync source swapping much more natural.
Furthermore, nothing uses gfxPlatform::GetGlobalVsync anymore, so it is removed.
Depends on D144374
| Assignee | ||
Comment 14•4 years ago
|
||
Depends on D144375
| Assignee | ||
Comment 15•4 years ago
|
||
randrSoftwareVsyncSource changes the rate on the main thread but reads it on the software vsync thread.
Depends on D144376
| Assignee | ||
Comment 16•4 years ago
|
||
Depends on D144377
| Assignee | ||
Comment 17•4 years ago
|
||
| Assignee | ||
Comment 18•4 years ago
|
||
| Assignee | ||
Comment 19•4 years ago
|
||
There are two issues currently preventing this from landing:
- A deadlock with the Wayland vsync source where calling EnableVsync synchronously calls NotifyVsync, so the VsyncDispatcher re-enters its own lock on the main thread. Should be easily fixable by moving the call to EnableVsync outside of the lock.
- A test failure on Linux where SoftwareVsyncSource destruction hits an assert about the software vsync thread not running. I haven't been able to reproduce this so far. It is possible that some thread machinery has already been torn down by the time that gfxPlatform shutdown destroys the software vsync source, but I'm not sure why we weren't hitting the assert without these patches. I'm still looking into this one.
| Assignee | ||
Comment 20•4 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #19)
- A deadlock with the Wayland vsync source where calling EnableVsync synchronously calls NotifyVsync, so the VsyncDispatcher re-enters its own lock on the main thread. Should be easily fixable by moving the call to EnableVsync outside of the lock.
I've made that fix and merged it into the patch "Invert the relationship between VsyncSource and VsyncDispatcher".
- A test failure on Linux where SoftwareVsyncSource destruction hits an assert about the software vsync thread not running. I haven't been able to reproduce this so far. It is possible that some thread machinery has already been torn down by the time that gfxPlatform shutdown destroys the software vsync source, but I'm not sure why we weren't hitting the assert without these patches. I'm still looking into this one.
This turned out to be really simple: mGlobalHardwareVsyncSource and mSoftwareVsyncSource were set to the same SoftwareVsyncSource, so we were calling Shutdown on the same object twice, which it didn't like. I'm now skipping the second call if they're the same object.
https://treeherder.mozilla.org/jobs?repo=try&revision=413911e41da0bffa2b65f0a874ffd98bd74f5bec
Comment 21•4 years ago
|
||
Comment 22•4 years ago
|
||
Backed out 16 changesets (Bug 1765399) for causing build bustages on RefPtr.h.
Backout link
Push with failures
Failure Log
Comment 23•4 years ago
|
||
Comment 24•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/41848c615ad4
https://hg.mozilla.org/mozilla-central/rev/d022091c31b6
https://hg.mozilla.org/mozilla-central/rev/821753cf91d4
https://hg.mozilla.org/mozilla-central/rev/c7fba6ee6573
https://hg.mozilla.org/mozilla-central/rev/255887544627
https://hg.mozilla.org/mozilla-central/rev/91854a447121
https://hg.mozilla.org/mozilla-central/rev/24fe85e709ba
https://hg.mozilla.org/mozilla-central/rev/22b568631834
https://hg.mozilla.org/mozilla-central/rev/90c803e44a4a
https://hg.mozilla.org/mozilla-central/rev/4b936873cd7c
https://hg.mozilla.org/mozilla-central/rev/5dd523c09fed
https://hg.mozilla.org/mozilla-central/rev/8ff003cb3864
https://hg.mozilla.org/mozilla-central/rev/9689f7bce600
https://hg.mozilla.org/mozilla-central/rev/a61caa52f560
https://hg.mozilla.org/mozilla-central/rev/1311628d0756
https://hg.mozilla.org/mozilla-central/rev/805110b54051
| Assignee | ||
Updated•4 years ago
|
Description
•