The prefs, when enabled, will dump the gecko DL items followed by the
WR DL items that were generated from that gecko item. This allows us to
easily go from a DOM element with known id/class attributes to e.g. an
ImageKey of an image that was generated for that element.
Also, this logging can be enabled in CI builds just like gecko display-list
dumping, instead of the ifdef that we previously had in WebRenderLayerManager.
MozReview-Commit-ID: Eeo4iO62YY1
--HG--
extra : rebase_source : b4a348b2e8bced976489257b966f70b29c56df25
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
Since bug 1457448 we can clear discarded animations on the same transaction where we send
animations to the compositor.
MozReview-Commit-ID: 4BYsCgA98S0
--HG--
extra : rebase_source : 95087b06037466ecf70a65e18561e48418376763
This code is unused now that ReadLockDescriptors are not sent in layer transactions.
--HG--
extra : rebase_source : 8cd25541b22c3151e2dbd2f8ea6d1119e2f26c94
extra : source : 99a2d26d1ba82ad34a6c27641500a424cda015c3
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
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
This code has been unused since the removal of layers-full WR codepaths.
MozReview-Commit-ID: JQn55Kbz5rr
--HG--
extra : rebase_source : af6995265c02a1ddfccbc37adb633bc2b240ec8b
This code has been unused since the removal of layers-full WR codepaths.
MozReview-Commit-ID: EAhRrZXLKKr
--HG--
extra : rebase_source : c33f915461c724c61b11804a9cecb960728fd6df
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 makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: GEZzCGbVqB1
--HG--
extra : rebase_source : dd4fab7f34da7c5465ba474db670cf583e8dadf4
This makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: 3yq9sPiHMge
--HG--
extra : rebase_source : 286423f56de59211e320f015cb1004a1e98332b8
