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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvbiWpAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvefJugoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvYLYowoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvdnHpAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvbDUrgoM


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

chromium-rel-mac-retina
chromium-rel-mac11

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

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


===== SUSPECTED CL(s) =====
Subject : Mac: Don't allow RenderWidgetHostViewCocoa to participate in autolayout.
Author  : tapted
Commit description:
  
WebContentsViewCocoa has a hook to resize all subviews to match its
size. The problem is that the size of a RenderWidgetHostViewCocoa is
allowed to get out of sync with its superview while waiting for a
WebContents paint to be committed. If an autolayout is triggered while
waiting for that commit, the WebContents thinks it's been resized and
spawns a new paint.

Since r424609, for 10.11+, Chrome stopped replacing the NSThemeFrame
(which AppKit does not support) and instead started using
NSFullSizeContentViewWindowMask. This seems to opt the window into
additional autolayout triggers, coming from CoreAnimation. This can
engage the code to "re-sync" the sizes of the RenderWidgetHostViewCocoa
and WebContentsViewCocoa when it wasn't done previously.

To fix, "re-sync" sizes in an override of -setFrameSize: rather than
-resizeSubviewsWithOldSize:. This ensures a re-sync only occurs when the
size of the WebContentsViewCocoa changes.

BUG= 655112 ,  655665 ,  264207 
TBR=sky@chromium.org

Review-Url: https://codereview.chromium.org/2442573003
Cr-Commit-Position: refs/heads/master@{#427290}
Commit  : ba268401a975c321f1e15ae3a4776fd3c60e268e
Date    : Tue Oct 25 06:44:31 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@427278  175.299  26.0862  5  good
chromium@427286  174.063  11.4153  8  good
chromium@427288  177.93   19.4061  8  good
chromium@427289  169.319  6.89317  5  good
chromium@427290  234.69   28.3474  8  bad    <--
chromium@427293  246.497  8.32381  5  bad
chromium@427307  239.163  13.285   5  bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 659621

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_ja_zh
Test Metric: timeToFirstContentfulPaint_avg/pcv1-cold/http___kakaku.com_
Relative Change: 36.43%
Score: 99.9

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


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

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