Regression in jitter metric |
||
Issue descriptionLooks like jitter regressed in the recent past: https://chromeperf.appspot.com/report?sid=5210c265c67a6f7f756cacaa6c2ad15913931afbf12781f3b5bb217c60f65f4d Did a bisect: https://chromeperf.appspot.com/buildbucket_job_status/9002246365142237904 Pointed at this CL: https://codereview.chromium.org/1939253002 Enne, any chance this could be related?
,
Sep 7 2016
Re #1 : Jitter page set has layers that are scrolled on compositor and there is javascript that undoes the scroll. So on every commit, the scrolling is undone on those layers and they move back to their original position. The metric runs on those pages and measures how much we have scrolled on the active tree before it was undone.
,
Sep 13 2016
Hmm. On OSX (but not on retina) I tried reproducing this, but was not able to. The value of the jitter metric locally for me appears to be roughly the same at r408172 (my patch), r407000 (before the jump), and r409000 (a day or so after). That said these results are pretty noisy even when I run it a few times, so it's hard to tell. Do you have any suggestions for reproducing this locally?
,
Sep 14 2016
Hmm, I can't think any easy ways to reduce the noise(except just increasing the repeat count). If you are getting the same values before and after the jump, maybe this is retina specific ?
,
May 8 2017
I was unable to ever reproduce this and unified begin frame is not going to unship at this point. Closing, sorry. |
||
►
Sign in to add a comment |
||
Comment 1 by enne@chromium.org
, Sep 7 2016