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

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


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

chromium-rel-mac11

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

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

Hi tapted@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 : 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@427284  224.047  7.81994  8  good
chromium@427288  216.344  2.44576  5  good
chromium@427289  212.912  3.09448  5  good
chromium@427290  238.762  10.4145  5  bad    <--
chromium@427291  243.529  6.23604  5  bad
chromium@427297  237.602  2.37458  5  bad
chromium@427309  233.658  8.25036  8  bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 659582

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_ko_th_vi
Test Metric: timeToFirstContentfulPaint_avg/pcv1-cold/http___www.danawa.com_
Relative Change: 6.11%
Score: 99.0

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


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

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

I think this is just returning to the levels since before the bug in r424609 was introduced.

Deleted: Screen Shot 2016-10-27 at 9.37.44 AM.png 146 KB

	Screen Shot 2016-10-27 at 9.37.44 AM.png 146 KB View Download

Deleted: Screen Shot 2016-10-27 at 9.39.05 AM.png 110 KB

	Screen Shot 2016-10-27 at 9.39.05 AM.png 110 KB View Download