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 adds a helper function for determining if the WebRenderBridgeParent
is for a content process and replaces uses with it appropriately.
MozReview-Commit-ID: 6YZhjYEYS3P
--HG--
extra : rebase_source : 97b0a86c4a2905d098ab199d6d1a1fd00c58a46d
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 commit adds a helper function for determining if the WebRenderBridgeParent
is for a content process and replaces uses with it appropriately.
MozReview-Commit-ID: 6YZhjYEYS3P
--HG--
extra : rebase_source : 8ecb1f9146376ac84b84680a5a3454200c940d6a
This was missed when the residual offset was added; it's correctly checked elsewhere
MozReview-Commit-ID: 44N5vDWLBIo
--HG--
extra : rebase_source : 37b42b8df416638e84531ed088c29716e4446159
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
On the non-WR codepath, the COMPOSITE_TIME probe records the time spent
in CompositorBridgeParent::ComposeToTarget, which does all the
compositing work from vsync to when stuff shows up on the screen. The
equivalent on the WR codepath is spread over multiple threads, but the
start is in WebRenderBridgeParent::ComposeToTarget and the end is when
we decrement the pending frame count in RenderThread. So we can
instrument those sites to record the interval.
MozReview-Commit-ID: 5EMUzBT1f6x
--HG--
extra : rebase_source : eafa7ea9931a3d3fb17b95dc9b9e4aa4ff9ff566
yaml.load() isn't safe and can lead to arbitrary code execution for
untrusted input. While probably not an issue here, I'm trying to
rid the tree of all yaml.load() instances so we can add a lint to
ban its usage.
Differential Revision: https://phabricator.services.mozilla.com/D1739
--HG--
extra : rebase_source : 4db69cde270b71335218b40d7b662c170854a6aa
extra : histedit_source : a740d99092c345ec8c6fcdb028498798c103b6a5
Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
This optimization also sneakily avoids the call to UpdateWithTouchAtDevicePoint
which is what updates the Axis::mPos variable to the new touch point. Without
that update, mPos remains at the touchstart point, which ensures that the full
pixel delta from all the touchmove events gets turned into scrolling. Without
this, the first touchmove event always gets consumed in the process of overcoming
the pan threshold, which lead to flaky test behaviour.
MozReview-Commit-ID: Io0zqgh8MZR
--HG--
extra : rebase_source : bc8aa93d694470a26ea7f220880364ff0eb29642
This is done by passing "--setpref apz.subtest=<subtest-name>" on the
mochitest command line, where <subtest-name> is the name of the subtest file
(including the extension).
MozReview-Commit-ID: EscFekIeOxr
--HG--
extra : rebase_source : a969553edfd0bd46b9ff0be695af621cf3e10bff
I had originally planned to land this as part of bug 1348321, with it
exercising the case from bug 1326290. However it exposed the issue that
I fixed in this bug, so it seems reasonable to land this test as part of
this bug.
MozReview-Commit-ID: EL1N9EmMXaC
--HG--
extra : rebase_source : 35ab71085e65929d287d9ba85025542ede7874f8
This saves us from having to constantly update this list. No functional
changes.
MozReview-Commit-ID: 5Vup4VKX2e8
--HG--
extra : rebase_source : b66e04795c40353caa4fe235dfd9b198a8bf20f4