This makes the sample time more "strongly typed" by using a variant-style
class instead of a raw TimeStamp. The sample time can come from different
sources (vsync, testing, Now()) and it is useful to save that information
as we pass around the sample time. It would have been helpful with some
of the debugging I did recently, and it also is needed for the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D86244
Currently on Android when CompositorVsyncScheduler detects that we requested a
composite more than 2 vsync intervals ago it forces an immediate composite. This
is a relic from times when vsync observation occured on the main thread, and
Fennec was single-process. (The logic being that if the main thread was busy and
it would be better to composite immediately rather than wait for the vsync
notification.)
Neither of these conditions are true nowadays, and geckoview should be no worse
than desktop platforms in this regard, so let's remove this code.
Depends on D85611
Differential Revision: https://phabricator.services.mozilla.com/D85612
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
The mNeedsComposite counter was used to force a composite immediately if
the scheduler received a number of composite requests without actually
getting a vsync. It was necessary on Fennec because of main-thread
contention. However it was wrong because it assumes only a single
composite gets requested per vsync interval, which is not true. Instead
of using a counter this patch uses a timestamp to ensure that we only
force the vsync after two vsync intervals have elapsed.
Depends on D8765
Differential Revision: https://phabricator.services.mozilla.com/D8766
--HG--
extra : moz-landing-system : lando
We are refactoring much of the code in gfx/vr, moving
most of the code that runs in the VRListenerThread into
it's own process. The remaining code will be non-blocking
once this refactoring is complete.
In order to resolve some shutdown crashes, it is simpler
to remove the VRListenerThread and the related code
starting and stopping this thread. If this is done
prior to completion of the refactoring for Bug 1473399
(Enable VRService thread by default), there would be a
regression in responsiveness during detection of VR
hardware due to blocking API calls moving off the thread.
Differential Revision: https://phabricator.services.mozilla.com/D7227
--HG--
extra : moz-landing-system : lando
Kartikaya Gupta
Jamie Nicol
Markus Stange
Kenny Levinsen
Noemi Erli
Jean-Yves Avenard
Narcis Beleuzu
Dorel Luca
Andrew McCreight
Ciure Andrei
Eric Rahm
Coroiu Cristina
Sylvestre Ledru
Nicholas Nethercote
Gurzau Raul
Daosheng Mu
Ehsan Akhgari
Matt Woodrow
Kearwood Gilbert
sotaro
Brian Hackett
Miko Mynttinen
arthur.iakab