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 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
The majority of this patch is just plumbing. The interesting parts are
in WebRenderLayerManager and APZUpdater/WebRenderScrollData. Unlike
ClientLayerManager, which updates the FrameMetrics on the client side
and sends the modified version over to the compositor, this WR version
just sends the update info over to the compositor, which then applies
the update to the metrics saved in APZUpdater before triggering the
hit-testing tree rebuild.
MozReview-Commit-ID: 4latUMa8RFw
--HG--
extra : rebase_source : d0aeaf5a9c8107bbcaf8b0da6d68a0f47f455be5
Changing the transaction id allocator is now handled better in
ClientLayerManager than before in that it resets the transaction id on
the new allocator to match the old allocator and avoid discontinuities
in the transaction ids. We should apply this behaviour to
WebRenderLayerManager as well, because WebRenderLayerManager was
assuming that any time the allocator changed it would automatically
start the transaction id at 1, which is not the case. In particular,
when navigating to something in the bfcache, we can reuse a pre-existing
refresh driver which might have a transaction id already greater than 1.
MozReview-Commit-ID: 8IUn1Dhnh7c
--HG--
extra : rebase_source : 0e98c96d9636c3a3ee0489ff6b6161bce7677dd7
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
The window buttons are drawn as part of the AddWindowOverlayWebRenderCommands
function which is invoked in the full-transaction codepath. It should be possible
to have the empty transaction codepath simply update the image (without building
a full WR display list) and do a recomposite. That would be more performant but
it requires some plumbing to build and ship across a IpcResourceUpdateQueue on
empty transactions.
MozReview-Commit-ID: 2Mrb0wELD6E
--HG--
extra : rebase_source : 9a94c32f94403050835bf3445176f4fe2c1579fa
This is functionally unrelated to the bug but I noticed it while fiddling with
the code, and the lines affected are kind of intertwined with the next patch so
I'm just doing the code removal as part of this bug.
MozReview-Commit-ID: CwmluhyCdbR
--HG--
extra : rebase_source : 0a86ba7299f63587b77c44fadc804e34ada5a474
This exposes the capacity of the underlying vec and sets it to the capacity of
the previous display list (mLastDisplayListSize). Doing so helps us avoid
reallocing up to the desired size every frame.
Note: the rebased version doesn't actually use a reasonable size. That will happen
in bug 1405819.
We have too many layers-free things in WebRenderLayerManager. I create a new
class WebRenderCommandsBuilder and move some functions and variables from
WebRenderLayerManager to WebRenderCommandsBuilder.
MozReview-Commit-ID: BJi1E51W7ax
--HG--
extra : rebase_source : ddbfb044d467430403a3c480030ef9dec803c9f7
Currently some callers attempt to set a "pending scroll offset update"
on the layer tree, which basically allows it to send a scroll offset
update to the compositor in an empty transaction, without doing a full
paint. However, WebRenderLayerManager doesn't really support empty
transactions yet, so we want to reject attempts to do this for now. This
will force the callers to schedule a full transaction instead of an
empty transaction.
MozReview-Commit-ID: 1bBlj59W5HH
--HG--
extra : rebase_source : 0a018989c2681b01ff325e8e2c79c9ff146f04d4
Instead of always discarding the compositor animation id, and then
sometimes un-discarding it (which involves a linear lookup in nsTArray),
this patch now has the WebRenderLayerManager keep a set of active
animation ids, and uses that to avoid discarding the same animation
twice.
In addition, because the display item can be destroyed at any time (e.g.
in the middle of an animation), we were previously "leaking" compositor
animations in that the compositor side never got notified to discard the
IDs. This resulted in infinite composition loops. This patch solves this
problem by having any unused WebRenderAnimationData trigger discard of
the animation id during destruction. This way, even if the nsDisplayItem
is deleted in the middle of the animation we have a fallback mechanism
to discard the id.
MozReview-Commit-ID: 8G3EYHcg9Kl
--HG--
extra : rebase_source : 45e99a0d71a76a15b7fc7a0d498a6149501a722d
If the compositor animations are still valid, we don't need to add its id to the discarded list.
This patch also reduces unnecessary SendDeleteCompositorAnimations calls.
MozReview-Commit-ID: AcbVUk3MUo7
--HG--
extra : rebase_source : fa8b1e5b4c9d3e81826eef621926975c967985a0
