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

Issue 594981 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Regression in Event.Latency.TouchToFirstScrollUpdateSwapBegin from M47 to M48

Project Member Reported by tdres...@chromium.org, Mar 15 2016

Issue description

The regression occurred between 47.0.2526.83 and 48.0.2564.95.

I haven't found any regression in telemetry that lines up well.
(https://chromeperf.appspot.com/report?sid=d33e7cec424e2e8eb023710ebdcecf2413f2dfe05b276e31f843d0874b284a90&start_rev=329229&end_rev=381190).

The regression occurred on Nexus 5, Nexus 5X, GT-I9500, GT-I9505, Nexus 6, Nexus 6P, and shows up clearly in the aggregate.

Anyone have thoughts on what could be going on here?
 
Regression is ~0.2ms in the median, ~90ms in the 90'th percentile.
TouchToScrollUpdateSwapBegin shows an improvement in the median, but a regression in the 99'th percentile at the same time.
Labels: OS-Android
This might also be the expensive task blocking change which we backported to M47: https://codereview.chromium.org/1617013002
Status: WontFix (was: Available)
Based on:

M46: No task blocking
M47: Aggressive task blocking (merged back from M48)
M48: No task blocking
M49: Less aggressive task blocking behind a finch trial
M50: Less aggressive task blocking behind a finch trial

It seems quite likely to me that this is due to us turning off task blocking in M48.

Marking WontFix.

Sign in to add a comment