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

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


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

linux-release

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

Hi senorblanco@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: fix pixel-moving filter effects on a rotated layer.
Author  : senorblanco
Commit description:
  
When a pixel-moving filter (e.g. blur, drop-shadow) is applied to a
transformed layer, we were leaving the edge equations used for edge-AA
at the original primitive's position, causing them to truncate the
effect (e.g., blur margins).

This fix detects that AA is required on a filter that changes the
bounds, disables edge-AA and bloats the boundaries by an extra pixel
instead.

This revealed that we were drawing the filtered result with NEAREST
filtering (!), causing some nasty jaggies when rotated. This was fixed by
manually setting the min and mag filters to LINEAR.

It also revealed that the software renderer was not
applying filter outsets. The GL renderer was previously
fixed here: https://codereview.chromium.org/1517693002. This
CL makes similar changes to the software renderer.

BUG= 607831 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/1942863002
Cr-Commit-Position: refs/heads/master@{#391332}
Commit  : c2061a305a361ebda94b0e46e80a69846b875cc5
Date    : Tue May 03 19:53:43 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@391299  50.3818  3.35754   8  good
chromium@391316  49.7445  2.52426   8  good
chromium@391324  48.7531  2.91425   8  good
chromium@391328  49.1537  3.60463   5  good
chromium@391330  48.239   0.212464  5  good
chromium@391331  47.6378  0.257372  5  good
chromium@391332  56.6961  2.67163   8  bad    <--

Bisect job ran on: linux_perf_bisect
Bug ID: 609116

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.tough_filters_cases
Test Metric: frame_times/http___rawgit.com_WebKit_webkit_master_PerformanceTests_Animometer_developer.html?test-interval_20_display_minimal_controller_fixed_frame-rate_50_kalman-process-error_1_kalman-measurement-error_4_time-measurement_performance_suite-name_Animometer_test-name_Focus_complexity_100
Relative Change: 10.39%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6469
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9013585618000333776


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

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

This only seems to be affecting bots without a real GPU (e.g., chromium-win7-rel-gpu-* are unaffected, as are all the Android bots I checked), so this is likely the changes to the software renderer. Since that was a pretty major correctness fix, it's unlikely we'll revert it. I suspect this benchmark happened to work without it, but many other pages wouldn't.