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.

RefreshTimerVsyncDispatcher manages a lot more than just the
RefreshDriverVsyncTimer these days.

Depends on D144362

Depends on D144363

Depends on D144364

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

Depends on D144366

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

Depends on D144368

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

Main thread observers (previously "generic" observers) are only used
by Windows touchpad scrolling so far.

Depends on D144370

Depends on D144371

This draws a clearer line between hardware vsync and software vsync.

Depends on D144372

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

This makes vsync source swapping much more natural.

Furthermore, nothing uses gfxPlatform::GetGlobalVsync anymore, so it is removed.

Depends on D144374

Depends on D144375

randrSoftwareVsyncSource changes the rate on the main thread but reads it on the software vsync thread.

Depends on D144376

Depends on D144377

https://treeherder.mozilla.org/jobs?repo=try&revision=6a764ebe41161b9f5916884fbe8377c5994284b6

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0a8f5640d7a5946651e6b3ded2138e689c0dfd17

There are two issues currently preventing this from landing:

1. 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.
2. 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.

(In reply to Markus Stange [:mstange] from comment #19)

1. 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".

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

Backed out 16 changesets (Bug 1765399) for causing build bustages on RefPtr.h.
Backout link
Push with failures
Failure Log

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