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
