New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 644558 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Regression in jitter metric

Project Member Reported by vollick@chromium.org, Sep 7 2016

Issue description

Comment 1 by enne@chromium.org, Sep 7 2016

Yes, it probably is.  What is jitter recording?

Comment 2 by enne@chromium.org, Sep 7 2016

What's also odd is that this was previously landed in r401796 and reverted in r402294 (June 23rd to June 27th), but the graphs don't appear to have changed in that spot.
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.

Comment 4 by enne@chromium.org, 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?
Screen Shot 2016-09-13 at 3.38.46 PM.png
129 KB View Download
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 ?

Comment 6 by enne@chromium.org, May 8 2017

Status: WontFix (was: Assigned)
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