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.
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
The goal of this patch is to remove the call to the sync IPC
GetCompositorOptions message from TabChild::InitRenderingState. In order
to this, we have InitRenderingState take the CompositorOptions as an
argument instead, and propagate that backwards through the call sites.
Eventually we can propagate it back to a set of already-sync IPC
messages in PCompositorBridge that are used during layers id
registration (NotifyChildCreated, NotifyChildRecreated, etc.). Therefore
this patch effectively piggybacks the CompositorOptions sync IPC onto
these pre-existing sync IPC messages.
The one exception is when we propagate it back to the AdoptChild call.
If this message were sync we could just use it like the others and have
it return a CompositorOptions. However, it is async, so instead we add
another call to GetCompositorOptions here temporarily. This will be
removed in the next patch.
MozReview-Commit-ID: AtdYOuXmHu4
