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

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


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

android-nexus5x-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15f8d31a640000

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

cc: Finish frame early if main thread is idle regardless of redraw state by enne@chromium.org
https://chromium.googlesource.com/chromium/src/+/430c8fbe06f29f492df7f212a9cc83d272d7634b
281.5 → 811.7 (+530.2)

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2e5401607fcfe8d434f2f91ae37a76222d9df322

commit 2e5401607fcfe8d434f2f91ae37a76222d9df322
Author: enne <enne@chromium.org>
Date: Mon Aug 27 20:41:09 2018

Revert "cc: Finish frame early if main thread is idle regardless of redraw state"

This reverts commit 430c8fbe06f29f492df7f212a9cc83d272d7634b.

Reason for revert: various perf regressions.
This should instead be solved via issue 874680.

Original change's description:
> cc: Finish frame early if main thread is idle regardless of redraw state
>
> This condition was added originally in this patch:
> https://codereview.chromium.org/27200003
>
> That patch was trying to trigger early deadlines when the compositor
> thread had work to do but the main thread had aborted.
>
> In a world where we have begin frame acks even when frames aren't
> produced, it's worth triggering early deadlines even when the compositor
> thread doesn't have any work to do either so that the display compositor
> can go ahead and do work earlier.
>
> This is intended as a short-term fix to solve smoothness issues with
> surface for video with 30fps videos.  Ideally the DisplayCompositor will
> have some followups as well so that one client that is slow to respond
> will not cause smoothness issues with another client.
>
> Bug:  874676 
> Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: I8b6663570aba7d135c1f211a21c37b1e17d19577
> Reviewed-on: https://chromium-review.googlesource.com/1176559
> Commit-Queue: enne <enne@chromium.org>
> Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#583908}

TBR=enne@chromium.org,sunnyps@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  874676 ,  875255 , 875316,  875323 ,  875328 ,  875424 ,  876099 
Change-Id: I4fd531fe07396ec2275bfd9109c8d86c6b4778f5
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/1191326
Commit-Queue: enne <enne@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586402}
[modify] https://crrev.com/2e5401607fcfe8d434f2f91ae37a76222d9df322/cc/scheduler/scheduler_state_machine.cc