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

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


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

android-webview-nexus5X
android-webview-nexus6

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

=== BISECT JOB RESULTS ===
Bisect failed for unknown reasons

Please contact the team (see below) and report the error.


Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : smoothness.gpu_rasterization.tough_path_rendering_cases
  Metric       : frame_times/https___testdrive-archive.azurewebsites.net_performance_chalkboard_


To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=https...testdrive.archive.azurewebsites.net.performance.chalkboard. smoothness.gpu_rasterization.tough_path_rendering_cases

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8980602351085065328

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5267846080233472


| 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 Speed>Bisection.  Thank you!

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

Blocking on crbug.com/713747 for busted android_webview_nexus6_aosp_perf_bisect.

=== BISECT JOB RESULTS ===
Bisect failed for unknown reasons

Please contact the team (see below) and report the error.


Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : smoothness.gpu_rasterization.tough_path_rendering_cases
  Metric       : frame_times/https___testdrive-archive.azurewebsites.net_performance_chalkboard_


To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=https...testdrive.archive.azurewebsites.net.performance.chalkboard. smoothness.gpu_rasterization.tough_path_rendering_cases

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8980598056008924512

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5267846080233472


| 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 Speed>Bisection.  Thank you!

I suspect this is https://chromium.googlesource.com/chromium/src/+/59df29deed59592d42ff7e600f33faf035e00b46

Feel free to reassign if I'm wrong.

senorblanco suggested this was likely due to path veto being busted from the PaintOpBuffer patch.  Will take a look.

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

commit 4b04a623b3af961b6284755050add2395e1d46f6
Author: senorblanco <senorblanco@chromium.org>
Date: Mon May 15 22:36:04 2017

cc: fix for MSAA veto.

(Tests by enne@.)

Recurse into RecordDrawOp when counting slow paths.
BUG= 718057 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2875343002
Cr-Commit-Position: refs/heads/master@{#471929}

[modify] https://crrev.com/4b04a623b3af961b6284755050add2395e1d46f6/cc/paint/paint_op_buffer.cc
[modify] https://crrev.com/4b04a623b3af961b6284755050add2395e1d46f6/cc/paint/paint_op_buffer.h
[modify] https://crrev.com/4b04a623b3af961b6284755050add2395e1d46f6/cc/paint/paint_op_buffer_unittest.cc

The above change has fixed the tough_path_rendering_cases regressions, but not the tough_filters_cases, so there must be another bug here.

Reminding myself to check this after https://codereview.chromium.org/2876033005 lands to see if display item list slow paths fix the tough filters case.

The NextAction date has arrived: 2017-06-05

Hmm, looks like the display item list slow path counting did not help the tough filters cases.  Some more investigation here is needed.

Any update on this?

Out of the 6 regressions, 3 have recovered soon afterwards, and one follows a previous improvements. We have two remaining, please investigate.

enne: any update?

I'm going to WontFix this.  This is likely due to something being not caught in counting slow paths (or vice versa) but this is already a heuristic.  This only regressed on one page of many and not elsewhere and so is a low priority to investigate and fix.  I'm going to just WontFix instead of leaving this to languish open and available.