This commit implements the CONTENT_FRAME_TIME metric for the webrender code
path. It follows the same structure as the previous commit implementing it for
the non-webrender code path.
MozReview-Commit-ID: 6aI5uISjgge
--HG--
extra : rebase_source : 973253589d6c27138bd49f4d81b3e74c3fcf5022
extra : histedit_source : 5b126b0285b674d59d8bd4b7bda09a01804dc043
This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
--HG--
extra : rebase_source : 29ebd6a85dd49ee263d50e3674eec4957ac5f12a
extra : histedit_source : 1aa9f4f31b5bff6736e0c0e576a5611880d0ab33
This commit implements the CONTENT_FRAME_TIME metric for the webrender code
path. It follows the same structure as the previous commit implementing it for
the non-webrender code path.
MozReview-Commit-ID: 6aI5uISjgge
--HG--
extra : rebase_source : acbf83d0071e8932b5e96016e6e39e27a7b4da8c
extra : histedit_source : a0f93f80441e5f45c0113244d15400d0f53d9c92
This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
--HG--
extra : rebase_source : cecb7149f50b2abe7a827dc20f1e8b8ade199258
extra : histedit_source : 581f8f38fc8335575d7275b903a8e1d6a9e5a369
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
In the next patch, we will introduce a new IPC function to get transform value
modified by both animations and APZC.
MozReview-Commit-ID: Uf5UHg5Jm
--HG--
extra : rebase_source : 68a52c110b049266ce982bc9284de8642dc3405d
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
Instead of notifying the AsyncImagePipelineManager on the compositor
thread via the CompositorBridgeParent, we can send it the new pipeline
info directly from the RenderThread after the update happens. This
effectively splits the AsyncImagePipelineManager update-processing into
two parts: one that takes in the new pipeline info and one that process
it. This allows us to invoke the processing step from other code running
on the compositor thread, which we will need to do in the next patch.
MozReview-Commit-ID: 7xhm8I7bY4C
--HG--
extra : rebase_source : bfa62e326fd830bc2ef771138e5008fb2bc0d6b8
In particular, this change makes it so that we are not holding the lock
when we clone the WebRenderAPI, because that can result in a deadlock.
MozReview-Commit-ID: 33OGZdFMjEA
--HG--
extra : rebase_source : 4a1aeb81e3316a119d6b0aa798d827314543a70b
With async scene building, we might get the message to delete certain
compositor animation ids while we are still building and rendering
scenes that have those compositor animations. This patch associates
those ids with the epoch at which they are safe to delete, and only does
the deletion once we have rendered that epoch.
MozReview-Commit-ID: Jetfcdtwt1q
--HG--
extra : rebase_source : f06b8ee62e460432e8faed670e928f60cb6bc915
This also rearranges the method implementation slightly to make the next
patch easier to read. This patch should have zero functional changes,
it's just refactoring.
MozReview-Commit-ID: 53StJ0TH3IT
--HG--
extra : rebase_source : 2f3aeb54271da75a7e051afc24b8a4c96f8496f2
With WR+async scene building, the updater thread is no longer the
compositor thread, but we can only send the IPC messages from the
compositor thread. So we need to bounce those calls over to the right
thread.
MozReview-Commit-ID: 6M9bSLYLi5n
--HG--
extra : rebase_source : d908f22892f9d531266f100eeb4a863cb63d8270
mCanSend was being cleared in ActorDestroy which is fine, but we
actually cannot reliably send IPC messages from CompositorBridgeParent
after we get a RecvWillClose message, because that's the last thing that
the child side sends before it gets destroyed. After the WillClose
message there's no guarantee that the child side actor will still be
alive. So this patch also sets mCanSend to false in RecvWillClose.
mCanSend is only used in two places, both of which have to do with the
APZ metrics-sharing code, so this shouldn't have any unexpected
side-effects. It is needed for the next patch.
MozReview-Commit-ID: 8CuFienWVUU
--HG--
extra : rebase_source : 11e4455ffd8cd281d0a16ca34feb63fa89338ccc
In the next patch, we skip updating animation value for the layer if the
animation value isn't changed. So without this patch, we will have to update
animation value even if the value isn't changed at all.
MozReview-Commit-ID: 9tU7BTkNOHL
--HG--
extra : rebase_source : 0dbaaab9e52108c843f2d378785a67a8f374994c
These tasks have an implicit ordering with other tasks that are
dispatched from the compositor thread to the updater thread, and so they
need to be bounced through the updater thread before we run them on the
controller thread.
MozReview-Commit-ID: 92nIYgyV8A2
--HG--
extra : rebase_source : c5edc5cb50dd44d1979d805bf17e707e1c8abac1
Same as the previous patch, but adapted for the sampler thread.
MozReview-Commit-ID: 7PVaPl38FkM
--HG--
extra : rebase_source : b7637270fea226cde15b9351a4ef8ac7ffab5796
This is possible if we just let the APZUpdater know during construction
if WR is enabled or not, and that information combined with the pref
will allow it to know whether to use the scene builder thread task queue
or just use the compositor thread as the updater thread.
MozReview-Commit-ID: 7IGMMtl7iFP
--HG--
extra : rebase_source : 3950adf77f4b48906b29cdb36f0437df1540bec6
This allows us to treat tasks from different layers id as independent,
thereby removing the unnecessary latency increase as described in bug
1449982 comment 33.
Note that we could probably implement this by actually maintaining
separate queues for each layers id, but that involves more overhead
since we would need to have a map from layers id to task queue, and
removing entries from that map becomes tricky with respect to locking
and timing.
MozReview-Commit-ID: 7jtYqNDwJqP
--HG--
extra : rebase_source : d55fa2c20c5e78a330033dcf049d5cc468024bb0
This will allow callbacks from rust code to get a handle to the
necessary APZUpdater instance on which to invoke functions.
MozReview-Commit-ID: 13XdzZrrtI5
--HG--
extra : rebase_source : 137af2a4c738a6e9294972be9e0566c9fdef58ac
This includes a signature change from CompositorBridgeParentBase ->
CompositorBridgeParent which is not strictly required, but it makes it less
likely that we'll accidentally create a WebRenderAPI from somewhere else
and pass a nonsense window id. In effect, the signature change makes it
likely that only CompositorBridgeParent will allocate the window ids.
MozReview-Commit-ID: 8AnnmI8RytR
--HG--
extra : rebase_source : 6fd957c4a9e5bb2175bee2cc89f7eb6d27a6bc9e
The APZUpdater class holds the methods that are to be run on the updater
thread. Note that there are a few differences between the APZSampler and
APZUpdater classes - most notably, APZSampler no longer has a
"RunOnSamplerThread" function because there should never be any need to
dispatch runnables to the sampler thread. There is still a
RunOnUpdaterThread in APZUpdater, as well as a mechanism for dispatching
runnables to the controller thread via the updater thread.
MozReview-Commit-ID: LLVWzRyhYWl
--HG--
extra : rebase_source : d3d2ae18b40f24473cab5567a48b67b8f478a733
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
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
It looks like we can get layer tree adopted messages when the compositor
doesn't have an entry for that layer tree in sIndirectLayerTrees. So we
need to null-check all the things we pull out of that structure - all
the properties are already null-checked except for the mParent. This
patch adds a null check around that as well.
MozReview-Commit-ID: 2fb4SdvgSrG
--HG--
extra : rebase_source : d6d053e1ae11288f4bfc5459993564ed6ba22133
This is important because the RecvInitialize method in CompositorBridgeParent
is run via a sync IPC message, and so we are guaranteed that when return to the
caller in the UI process, the APZCTreeManager will have been created. This
ensures that when we create the APZInputBridge actors (which will happen on a
different top-level protocol, but be triggered after the sync RecvInitialize
is complete) we know that the concrete APZCTreeManager is ready for use.
MozReview-Commit-ID: KYDyJNXxQJm
--HG--
extra : rebase_source : f7bbd000a94e405322ceaed6823693e4a95c81d4
This code was originally added to debug the frame visibility code.
However it wasn't architected correctly and makes the compositor use an
untrusted layers id from content. Instead of fixing this I'd rather just
delete it, since it's a big pile of code that is basically a debugging
tool that nobody owns anymore.
MozReview-Commit-ID: nPZqVeYsFp
This changes the lifecycle and API for TextureReadLock to fix file descriptor exhaustion
crashes. These changes are partially superficial and mostly align the API of TextureReadLocks
with their actual usage.
The changes are:
1. Create the TextureReadLock in the TextureClient constructor so it's available before IPC creation
a. This is superficial as EnableReadLock was always called before IPC creation
2. Send the ReadLockDescriptor in the PTextureConstructor message and close the file handle
3. Receive the ReadLockDescriptor in TextureHost and close the file handle
4. Send a boolean flag in layer transactions if the texture is read locked instead of a descriptor
5. Use a boolean flag in TextureHost to determine if the ReadLock must be unlocked instead of a nullptr
I believe that we can remove the InitReadLocks code from LayerTransaction as that was added to
prevent file descriptor limits in IPDL messages and is no longer needed with this change. But
that is a non-essential change and this patch is already big enough.
MozReview-Commit-ID: DzHujrOQejH
--HG--
extra : rebase_source : 3bdd7c9bc8edfdc386faad8a9e59ad7dc18ed91d
We can easily populate the mId with the correct layers id, which is the
root layer tree id from the CompositorBridgeParent. This eliminates a
bunch of special-case handling.
MozReview-Commit-ID: FEkboAGEhYO
--HG--
extra : rebase_source : 01e73d516e5742d586cbf6d8b6bc5c9f7d64f141
Callers should be using one of the more specific subinterfaces like
IAPZCTreeManager (for controller-API methods) or APZSampler (for
sampler-API methods). There's also a bunch of android-specific
dynamic toolbar code that uses this function - I don't want to
deal with that right now, so instead of removing it entirely we can just
make it Android-only.
MozReview-Commit-ID: I8DYWLYoFgP
--HG--
extra : rebase_source : 75e05825194f9c6843506bb5d82e1a0c6e2b08bb
Although CrossProcessCompositorBridgeParent still needs to create a
dummy APZCTreeManager of its own in place, we can at least stop it from
grabbing the "real" APZCTreeManager from CompositorBridgeParent, which
allows access to methods that might not be properly guarded with respect
to thread safety.
MozReview-Commit-ID: Btvez3OkFPs
--HG--
extra : rebase_source : a4bec1769ff2fb899bb2e65f99f8e715f9a94c44
This interface should be used for accessing any sampler-thread functions
on APZCTreeManager. Eventually the interface will handle thread
delegation so that if it is called from a thread that is not the sampler
thread it will redirect the calls appropriately. For now it just allows
to logically group the public APZCTreeManager methods that are to be run
on the sampler thread.
MozReview-Commit-ID: GArPvjfuYYr
--HG--
extra : rebase_source : 884cf6c3ce00f3df8ffe7dfa5fc12ef971f3cefc
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
--HG--
extra : rebase_source : ab24190a12053db06192fab4d1b7a932fe2d1724
The sampler thread is similar to the controller thread in that it doesn't
correspond to a particular actual thread, but instead introduces an
abstraction that allows us to reason about code flow and data ownership
that is logically grouped on a single thread. For now the sampler thread
remains mapped to the compositor thread, but eventually we will allow
it to be render backend thread when webrender is enabled.
MozReview-Commit-ID: D6i2t5lDvkv
--HG--
extra : rebase_source : 06211ad878973c76ca3fd618386bbbd0cfdd4821
This encapsulates the APZTestData better inside APZCTreeManager, which
we will want once we allow the hit-test tree update to happen on a
thread other than the compositor thread.
MozReview-Commit-ID: 66uSsagVfEu
--HG--
extra : rebase_source : 8e6ae809bfa0dde4e0e5fb2e321dd315174eafd6
Patch originally attached to - and reviewed by sotaro on - bug 1432708.
MozReview-Commit-ID: LNWHtuFTPG5
--HG--
extra : rebase_source : c1694476cb454d914f2cfe3ec7cf55aaa0aacd4c
It looks like the call chain is called ScheduleComposite on the client
LayerManager API, but then for some reason the functions in the IPDL
bridges are called ForceComposite, and then they eventually call the
ScheduleComposition function on the CompositorVsyncScheduler. This is
silly, so I renamed the IPDL bridge functions to ScheduleComposite as
well to be consistent.
MozReview-Commit-ID: D7bWpASaEtb
--HG--
extra : rebase_source : ecb0494d9461bd4ada48bfb602e7b518f0601c1b
SetTestSampleTime is called from tests via the advanceTimeAndRefresh API
on DOMWindowUtils, and the expectation is that after it is done, the
time has been advanced and a composite has happened. So we need to
ensure that is the case with WebRender as well. This fixes the issue I
was seeing with test_group_hittest.html and makes it pass.
MozReview-Commit-ID: 86l9mTTwD2v
--HG--
extra : rebase_source : d2921fb0f9b09f4366fb516e4a6254a7f13f3e4e
This splits the FlushRendering function into sync and async versions
just for a bit more clarity. In the async version we don't want to set
the mForceRendering flag at all because we don't need to force a
rendering - if there is one already pending then that's good enough. And
anyway in practice the async version seems to only ever be invoked by
CompositorBridgeParent::SetTestSampleTime which I'll be changing in the
next patch.
MozReview-Commit-ID: 4cdU0U5B1pp
--HG--
extra : rebase_source : d7842844fca758d53121e3326d8da7fb7592ad8b
Having a resume function without a corresponding pause function seems
silly. And the implementation of the function is the same as doing a
force-compose, which is what the call site is intending to do. So we can
just remove this function and do a force-compose instead.
MozReview-Commit-ID: LimMYQhAuEk
--HG--
extra : rebase_source : f10e43c4c4a6f67162b1b473de6c23d8dbdc7a8f
CompositorBridgeParent::GetIndirectShadowTree is meant to be a
compositor thread only method. This however was not enforced with an
assert and over time we began using it on the main thread for simple
accesses. These accesses should generally be safe on the main thread,
depending on the individual access, but not outside the lock
GetIndirectShadowTree holds. As such, a safer variant is provided to
execute a lambda inside the lock context, and the unsafe variant will
assert it is indeed in the compositor thread context.
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
It seems like a footgun to expose raw pointers to WebRenderAPI which is
a refcounted object. Let's only expose it via refcounting pointers.
MozReview-Commit-ID: AKmTZg2V99r
--HG--
extra : rebase_source : 805f13d56a64bafbcdf3bf4266eec47c70856564
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
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
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.
Jim Chen
Kartikaya Gupta
Brian Hackett
Ryan Hunt
Narcis Beleuzu
sotaro
Chris Peterson
Bogdan Tara
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Dorel Luca
James Willcox
shindli
Sebastian Hengst
Tristan Bourvon
Brindusan Cristian
Nicolas Silva
Andrew Osmond
Andrew McCreight
Daniel Holbert
Coroiu Cristina
Daosheng Mu
Nicholas Nethercote