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

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


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

win-zenbook

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

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


=== Bisection aborted ===
The bisect was aborted because The metric values for the initial "good" and "bad" revisions do not represent a clear regression.
Please contact the the team (see below) if you believe this is in error.

=== Warnings ===
The following warnings were raised by the bisect job:

 * Bisect failed to reproduce the regression with enough confidence.

===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N   Good?
chromium@428136  78.1468  1.74551  18  good
chromium@428254  78.0333  2.34255  18  bad

Bisect job ran on: winx64_zen_perf_bisect
Bug ID: 661541

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests smoothness.top_25_smooth
Test Metric: percentage_smooth/Blogger
Relative Change: 0.94%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64_zen_perf_bisect/builds/582
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8997106645182831872


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

| 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!

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

I can confirm that we also detected a strong performance regressions for many of the sub-scores of the top_25_smooth benchmark. In particular, the score 'percentage smooth' for the top_25_smooth/www.weather.com dropped from ~45% to 0% (this scores refer to the Chromebook named veyron_jerry, which is the ChromeOS overlay corresponding to the Hisense Chromebook 11). We observed a similar drop for other Chromebooks. The average frame duration almost doubled. A similar situation occurs for other sub-scores of the top_25_smooth benchmark (news.yahoo.com, games.yahoo.com, techcrunch.com). The effect can be spotted with naked eye while the benchmarks are running.

The patch responsible for the regression is https://codereview.chromium.org/2449853004 and I double checked that reverting this patch makes these scores go back to normal. I also managed to localise the problem, which originates in the method DirectCompositorFrameSink::ForceReclaimResources() in cc/surfaces/direct_compositor_frame_sink.cc. This method calls SurfaceFactory::SubmitCompositorFrame(), passing an empty Frame() (created just doing a `CompositorFrame()'). This empty frame ends up being passed to Surface::Queue(). The original intent - I think - was to clear the frame queue and free all resources associated with the current_frame_. This doesn't happen anymore. I could fix the issue by creating a separate Surface::ClearQueue() method which does what Surface::QueueFrame() did when passed a null frame (before the patch, when null frames still existed).

I have noticed, however, that Saman Sami is now looking into this issue at https://codereview.chromium.org/2504033002/. Just let me know if you want me to upload my fix.

===== BISECT JOB RESULTS =====
Status: failed


=== Bisection aborted ===
The bisect was aborted because Bisect cannot identify a culprit: Bisect failed to reproduce the regression with enough confidence.
Please contact the the team (see below) if you believe this is in error.

===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N   Good?
chromium@428590  78.7481  8.6198   27  good
chromium@428592  79.4138  8.18294  27  bad

Bisect job ran on: winx64_zen_perf_bisect
Bug ID: 661541

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=Blogger smoothness.top_25_smooth
Test Metric: percentage_smooth/Blogger
Relative Change: None

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64_zen_perf_bisect/builds/603
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8995832569982542240


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

| 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!

Matteo,
We have already reverted the CL of mine that caused this problem. We are going to bring it back with a fix some time in the near future. Your explanation and solution also seem to be in line with what we have in mind.

These regressions happened before M56 branch. M56 is now in stable. These regressions made it to the stable channel. Marking wontfix.

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