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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg7cqVqAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgnbTZpgoM


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

chromium-rel-mac11

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8998431991773815856

=== Auto-CCing suspected CL author danakj@chromium.org ===

Hi danakj@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : cc: Get rid of PostSwapBuffersComplete.
Author  : danakj
Commit description:
  
OutputSurface and CompositorFrameSink both have this method which is
not part of the interface but used to post a call to the client's
DidSwapBuffersComplete to the current ThreadTaskRunnerHandle. This is
problematic since that is *not* the compositor task runner which can
be overridden, and it clutters these base class APIs.

This moves the calls to the client DidSwapBuffersComplete() out to each
implementation of OutputSurface or CompositorFrameSink.

Some additional changes in the process:

- BrowserCompositorOutputSurface had OnGpuSwapBuffersCompleted but it
was only used for gpu cases, so moved to GpuBrowserCompositorOutputSurface
and remove the NOTREACHED() version in
SoftwareBrowserCompositorOutputSurface.

- Blimp was not using the draw callback to provide backpressure for
submitted CompositorFrames, and just posting immediately, so hook that
up instead of doing a simple post-task dance there.

- SoftwareBrowserCompositorOutputSurface was using ThreadTaskRunnerHandle
to make another post task too but it should be using the compositor's
task runner. Since it now has it, use that.

R=enne@chromium.org, khushalsagar@chromium.org
BUG= 616973 , 606056 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2402173002
Cr-Commit-Position: refs/heads/master@{#424294}
Commit  : daad1d10fb3932de760bdc3688e96c947d3c7b18
Date    : Tue Oct 11 00:02:27 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N   Good?
chromium@424272  162.512  87.2337  12  good
chromium@424284  143.037  22.4795  12  good
chromium@424290  140.81   21.1828  12  good
chromium@424293  144.949  23.7049  18  good
chromium@424294  172.018  14.8805  8   bad    <--
chromium@424295  173.16   11.7197  18  bad
chromium@424296  175.362  2.13447  12  bad
chromium@424320  168.876  17.3632  8   bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 657131

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests page_cycler_v2.intl_es_fr_pt-BR
Test Metric: timeToFirstMeaningfulPaint_avg/pcv1-warm/http___www.free.fr_adsl_index.html
Relative Change: 18.45%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/969
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8998431991773815856


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5781878055895040

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Graphs look like they are hugely noisy and this was just faster for a few runs then went back to normal.