Remove VsyncSource::Display
Categories
(Core :: Graphics, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox100 | --- | fixed |
People
(Reporter: mstange, Assigned: mstange)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
We have the cross-platform interfaces VsyncSource and VsyncSource::Display. Every platform has an implementation for each of those. But we don't end up using the Display abstraction at all: Every VsyncSource currently only has a single Display associated with it.
I think the Display abstraction is not worth having, and we should merge it into VsyncSource.
Originally, the intention of the Display abstraction was to use it for per-monitor vsync. There would be one software VsyncSource and one hardware VsyncSource, and the hardware VsyncSource would have one Display per screen. But in reality, things have played out differently: The only platform with per-monitor vsync is currently Linux Wayland, which has per-widget vsync. And it has chosen to have one VsyncSource per widget, with a single Display each.
For the macOS implementation of per-monitor vsync, I think it also makes sense to have one VsyncSource per screen.
We already need to handle switching between VsyncSources, for switching between software and hardware vsync, if the pref layout.frame_rate is changed. So we might as well reuse that same switching capability for switching between screens, when a window moves between screens or when a tab moves between windows on different screens.
|
Assignee | |
Comment 1•2 years ago
|
||
Every VsyncSource currently only has a single Display associated with it.
This means that we're not making use of the Display abstraction at all.
This patch gets rid of Display by merging it into VsyncSource.
Originally, the intention of the Display abstraction was to use it for
per-monitor vsync. There would be one software VsyncSource and one hardware
VsyncSource, and the hardware VsyncSource would have one Display per
screen. But in reality, things have played out differently: The only platform
with per-monitor vsync is currently Linux Wayland, which has per-widget
vsync. And it has chosen to have one VsyncSource per widget, with a single
Display each.
For the macOS implementation of per-monitor vsync, I think it also makes
sense to have one VsyncSource per screen.
We already need to handle switching between VsyncSources, for switching
between software and hardware vsync, if the pref layout.frame_rate is
changed. So we might as well reuse that same switching capability for
switching between screens, when a window moves between screens or when a
tab moves between windows on different screens.
|
|
Assignee | |
Comment 2•2 years ago
|
||
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/aa1f738fc3c4 Merge VsyncSource::Display into VsyncSource. r=smaug
|
||
Comment 4•2 years ago
|
||
| bugherder | ||
Description
•