WebRenderBridgeParent holds uninitialized mPipelineId when it was created by WebRenderBridgeParent::CreateDestroyed(). Then when CrossProcessCompositorBridgeParent::DeallocPWebRenderBridgeParent is called for the WebRenderBridgeParent, it will call EraseLayerState with some garbage uninitialized value, and so it will erase some random layer state entry.
Previously, the WebRenderBridgeParent for each content layer tree would use the
same WebRenderAPI instance as the top-level WebRenderBridgeParent for that window.
However, in order to make the namespacing changes work we now need to use a
separate WebRenderAPI instance for each WebRenderBridgeParent. The content
WebRenderAPIs are cloned from the parent one, so that they all share the same
backend, but can allocate resource IDs in distinct namespaces.
MozReview-Commit-ID: 7VTFL8F09n7
--HG--
extra : rebase_source : 2da1d03abc23bd7852e4b12fe133889bd80cad53
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.
The patch removes CompositorBridgeParentBase::GetAnimationStorage and CrossProcessCompositorBridgeParent::GetAnimationStorage, and remove the "aId" parameter to CompositorBridgeParent::GetAnimationStorage, since it's only ever called with "0" as the argument.
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
When the tab move happens, related non-root WebRenderBridgeParent is updated as to render to different webrender instance. webrender does not support of sharing resources and keys yet. Then when the tab move happens, the patch just removes all keys and resources that belongs to previous webrender. Ideally all resources that belong to WebRenderBridgeParent should be reallocated in an update webrender. But the patch does not do it, instead it just request WebRenderBridgeChild to re-allocate all resources again for simplicity. Performance improvement will happen in a future patch.
This patch support only tab move that uses only raw data external images. Support of native texture external images will happen in a future patch.
When the tab move happens, related non-root WebRenderBridgeParent is updated as to render to different webrender instance. webrender does not support of sharing resources and keys yet. Then when the tab move happens, the patch just removes all keys and resources that belongs to previous webrender. Ideally all resources that belong to WebRenderBridgeParent should be reallocated in an update webrender. But the patch does not do it, instead it just request WebRenderBridgeChild to re-allocate all resources again for simplicity. Performance improvement will happen in a future patch.
This patch support only tab move that uses only raw data external images. Support of native texture external images will happen in a future patch.
This allows testing code control over the animation steps running over in the
compositor, which is needed for the OMTA mochitests.
MozReview-Commit-ID: CXJcieSEoRl
--HG--
extra : rebase_source : ad73196ac835e7aae0003befa8c71e81a9019dd2
This will make these functions usable from WebRenderBridgeParent, which has a
layers id but doesn't have a LayerTransactionParent.
MozReview-Commit-ID: FvxGPdLeUWe
--HG--
extra : rebase_source : eaed5dedeccda41068cade3d5b4527d0f047eed9
This commit modifies PresShell and nsDisplayList to send a FocusTarget update on
every layer transaction. Ideally we would like to send updates as often as possible,
but this seems like it works well. This can be iterated on later, if necessary.
MozReview-Commit-ID: 8PFqIOhzH77
--HG--
extra : rebase_source : 1e2c3b5620f5d7e6e789848da57b2486c3d74f14
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
PROFILER_MARKER is now just a trivial wrapper for profiler_add_marker(). This
patch removes it.
--HG--
extra : rebase_source : 9858f34763bb343757896a91ab7ad8bd8e56b076
This patch does the following.
- Renames some ProfilerMarkerPayload subclasses so they all of the form
"FooMarkerPayload", to make the subclass relationship clearer.
(ProfilerMarkerTracing -- now TracingMarkerPayload -- was the worst
offender.)
- Removes ProfilerMarkerImagePayload and TouchDataPayload, neither of which are
used.
- Changes streamCommonProps() to StreamCommonProps().
- Does some minor style and comment fixes in ProfilerMarkerPayload.h.
--HG--
extra : rebase_source : dd732905e96da83bcbf124c70b20011c661fc332
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.
This bug handles abnormal client shut down case and Tab move between different windows.
Abnormal client shut down case, WebRenderBridgeParent does not receive IPC messages that are sent during WebRenderLayerManager and WebRenderBridgeChild destruction. In this case, animations under the WebRenderBridgeChild are not removed from CompositorAnimationStorage. Abnormal shut down could happen when content process was crashed or content process was killed by ContentParent if shutdown takes too long time.
In the tab move case, the WebRenderBridgeParent will need to be re-bound to a different CompositorBridgeParent and CompositorAnimationStorage, and so will need to clear all its active animations from the old CompositorAnimationStorage and add animations into the new CompositorAnimationStorage. This will happen in a future patch.
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
This makes it simpler to reuse this API from WebRenderBridgeParent,
since we can provide a layers id but not a LayerTransactionParent.
MozReview-Commit-ID: DEIGMk9tJEB
This is helpful for reusing the FlushApzRepaints from
WebRenderBridgeParent, since it no longer assumes there's a layers
transaction object.
MozReview-Commit-ID: GVqDDEeZaN3
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
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
This call should be a no-op in the real world, and should be safe to
remove. The patch also adds an assert to ensure that the call is
effectively a no-op.
MozReview-Commit-ID: BXdcnHULWW2
--HG--
extra : rebase_source : 03c57d2d6dbfb1d330ce7eab6d842d8375d33208
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
--HG--
extra : rebase_source : 5b80831cf84d3a4b57b2214a12ccf8a896cfa3a7
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
This patch is not strictly relevant to the current bug, but doing the
work here nicely illustrates how the constructor we added in part 1 can
be used in existing parts of the codebase.
