VsyncDispatcher::NotifyVsync can be called from two different threads
at the same time, if it just swapped out its vsync source and the old
vsync source is still notifying it. So we need to protect mVsyncSkipCounter
behind a lock.
Differential Revision: https://phabricator.services.mozilla.com/D148958
This makes vsync source swapping much more natural.
The VsyncSource now only has a reference to the VsyncDispatcher for the duration
during which the dispatcher is listening to vsync. Whenever the dispatcher is
not listening to vsync, the source has no reference to the dispatcher and there
is no cycle.
This patch also adds the ability to register multiple dispatchers with the same
source. This ability is not used yet; a vsync source always has zero or one
dispatchers at the moment. It is in preparation for a future patch where there
will be one dispatcher per widget.
Furthermore, nothing uses gfxPlatform::GetGlobalVsync anymore, so it is removed.
Differential Revision: https://phabricator.services.mozilla.com/D144375
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.
Differential Revision: https://phabricator.services.mozilla.com/D144366
This makes vsync source swapping much more natural.
The VsyncSource now only has a reference to the VsyncDispatcher for the duration
during which the dispatcher is listening to vsync. Whenever the dispatcher is
not listening to vsync, the source has no reference to the dispatcher and there
is no cycle.
This patch also adds the ability to register multiple dispatchers with the same
source. This ability is not used yet; a vsync source always has zero or one
dispatchers at the moment. It is in preparation for a future patch where there
will be one dispatcher per widget.
Furthermore, nothing uses gfxPlatform::GetGlobalVsync anymore, so it is removed.
Differential Revision: https://phabricator.services.mozilla.com/D144375
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.
Differential Revision: https://phabricator.services.mozilla.com/D144366
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.
Differential Revision: https://phabricator.services.mozilla.com/D140891
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
Lets Wayland sessions run vsync off wayland surface frame callbacks by creating
an interface for widgets to return a local VsyncSource, if applicable.
This interface is currently used for the compositor, and for refresh drivers
in the parent process. It is not yet used for vsync in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D28430
--HG--
extra : moz-landing-system : lando
This requires:
- Moving the constructors of ProfilerMarkerPayload and its subclasses into the
.h file so they are visible even when ProfilerMarkerPayload.cpp isn't
compiled.
- Similarly, using a macro to make StreamPayload() a crashing no-op when the
profiler isn't enabled. (It is never called in that case.)
--HG--
extra : rebase_source : 7aad2fdb1bd4e49782024dba6664e8f992771520
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
Because ProfilerMarkerPayload is the main type defined in these files, and
because the next patch is going to introduce ProfilerMarker.{h,cpp}, which
would be confusingly similar to the old names.
--HG--
rename : tools/profiler/core/ProfilerMarkers.cpp => tools/profiler/core/ProfilerMarkerPayload.cpp
rename : tools/profiler/public/ProfilerMarkers.h => tools/profiler/public/ProfilerMarkerPayload.h
extra : rebase_source : df22a2ab3867650348ae78fe959ff0366aff230b
ScreenManager takes the common parts of ScreenManagerWin,
ScreenManagerGtk and ScreenManagerCocoa. It caches all screen
information in the new Screen class. The cache are updated when the OS
notifies there is a monitor config change; all changes will be pushed to
content processes via PContent (patch part 6.)
Screen is a pure data object. All platform dependent logic will be in
widget specific helper classes.
Each process will have a singleton ScreenManager object. Widget
specific helper object is held alive by the ScreenManager when
necessary, for example to receive updates from the OS.
The change to to VsyncDispatcher.cpp is due to unified-build bustage.
ScreenManager::ScreenForNativeWidget is not implemented because it
will be removed in patch part 6.
MozReview-Commit-ID: 5ezytAXSqHp
***
fixup
MozReview-Commit-ID: DQtq3UVZytA
--HG--
extra : rebase_source : c1a5aac713de783586e93109fe3e197ffdc1a3ca
serge-sans-paille
Cristian Tuns
Florian Quèze
Markus Stange
Bas Schouten
Marian-Vasile Laza
Kenny Levinsen
Coroiu Cristina
Mihai Alexandru Michis
Andrew McCreight
Ciure Andrei
Matt Woodrow
Sylvestre Ledru
Brian Hackett
Nicholas Nethercote
Bill McCloskey
Carsten "Tomcat" Book
Kan-Ru Chen
David Anderson
Kyle Huey
Mason Chang