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
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
When double buffering is enable with compositor, DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL is used without DirectComposition. There are some devices that swap chain with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL does not work well. In this case, device reset happens very often. To avoid the situation, the double buffering needs to be disabled when device reset happens.
Differential Revision: https://phabricator.services.mozilla.com/D36579
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
On android, android's nsWindow creates LayerManaer only in nsWindow::Create(). When WebRender error happened, gecko just stopped rendering by disabling Webrender.
The nsWindow needs to re-create LayerManager during disabling Webrender. Further, during disabling WebRender, All GeckoSurfaceTextures should not be attached to GLContext. It is for preventing a conflict with AttachToGLContext() call in SurfaceTextureHost::EnsureAttached().
Differential Revision: https://phabricator.services.mozilla.com/D26687
If the GPU process becomes disabled due to crashes, then we should not
allow Linux to fallback from WebRender to OpenGL compositing in the
parent process. It should instead fallback to software just like
Windows. This is important because we don't support the OpenGL
compositor configuration.
Differential Revision: https://phabricator.services.mozilla.com/D34360
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
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
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
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
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
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
When the compositor thread has begun shutdown, it will spin the event
loop for the main thread until the last CompositorThreadHolder reference
has been released. While spinning, new IPDL objects may be attempted to
be created which depend on the compositor thread; we should check to
ensure the compositor thread is still around before proceeding with
creation. These objects include CompositorManagerParent,
ImageBridgeParent, and VRManagerParent. Additionally there is a very
similar bug between the vsync thread and VsyncBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D23308
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
This just adds the boilerplate that goes with the new protocol, without
adding any of the actual messages. The protocol is managed by PGPU, and
there will be one instance per compositor. The parent side lives on the
main thread of the GPU process, and the child side lives on the main
thread of the UI process. The protocol is only instantiated if the GPU
process is active.
MozReview-Commit-ID: J4VzwmEfYTa
This static function has only two call sites. One (in GPUProcessManager)
is unused, so it can be removed. The other (in
InProcessCompositorSession) takes the returned APZCTreeManager and
exposes it as an IAPZCTreeManager. Instead of doing this, we can simply
expose it as an IAPZCTreeManager from CompositorBridgeParent itself, to
reduce the number of places that can potentially grab a handle to the
APZCTreeManager.
MozReview-Commit-ID: BjLf6GSsnKz
GPUProcessManager::EnsureGPUReady promises that its state will be
consistent after returning. Either the GPU process is ready to be used,
or there is no GPU process at all. In the case it is attempted to
synchronously initialize the GPUChild with the device data and failed,
it broke that promise. This is because the GPU process was still setup,
but we weren't going to use it. This became a problem with the
CompositorManagerChild because it uses the process token as an
identifier, and it should have been reset to 0 in this case.
Now if GPUChild::EnsureGPUReady (the initialization step) fails, we
disable the GPU process entirely. This ensures our internal state is
consistent and the callers expectations are upheld.
