All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=822880

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=53343cc1dd7f44ee3edd5b4c34560b6213b384d1d851c8e048f89e2bbab49006


Bot(s) for this bug's original alert(s):

android-webview-nexus5X

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/154956be440000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/154956be440000

 Issue 822879  has been merged into this issue.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16a64ce3c40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/16a64ce3c40000

Don't set active_tree_needs_first_draw_ on invalidate by jamwalla@chromium.org
https://chromium.googlesource.com/chromium/src/+/989dd34c86ee3a462c467d0c4200faa9046fa496

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

+boliu

We expected regressions here, activation has to wait for previous frame's draw. (see  issue 821024 .) But this is a >1ms regression, so on the order of 10% of the frame. Don't know if that's acceptable, but I'm looking at traces now.

I agree queuing duration on the compositor thread going up makes sense for that change, assuming that's what that metric is measuring..

Yep, this is measuring queuing duration. It runs a simple animation while also evaluating some nasty javascript: https://cs.chromium.org/chromium/src/tools/perf/page_sets/tough_scheduling_cases/_second_batch_js_generator.py

 Issue 821894  has been merged into this issue.