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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_tWUvgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggYykrQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_smWqQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggYyDqwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_pnXswoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_sTC6AsM


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

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

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

Bisect failed: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_bisect/builds/2338
Failure reason: the build has failed.
Additional errors:
The metric was not found in the test output.
Either of the initial "good" or "bad" revisions failed to be tested or built.

kouhei@: There are quite a few big regressions in page_cycler_v2 recently, and bisects are always failing to find the cause(s). I am assigning the bugs to you since you seem to have made many (most?) PCv2 changed recently. If I am wrong, could you please help me find the right owner of these bugs?

There's a problem with bisecting PCv2 

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

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

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

Hi enne@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 : Fix jank during mac resize
Author  : enne
Commit description:
  
Allow SetNeedsBeginFrames messages to be handled on Mac during resize.
If this message is not handled, then the renderer says that it needs
frames but the message is ignored because of the resize lock.  Then, the
browser never sends begin frame messages and the renderer then never is
able to produce a frame.  This means that it can't produce a frame of
the right size before the resize lock times out and there's jank on
screen.

R=ccameron@chromium.org,sievers@chromium.org
BUG= 632603 ,638561

Review-Url: https://codereview.chromium.org/2246613002
Cr-Commit-Position: refs/heads/master@{#413601}
Commit  : e5ce61d4966237e3572f3048a6ea39c7ba7d7c64
Date    : Tue Aug 23 00:27:11 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@413566  192.985  53.1272  5  good
chromium@413590  192.918  61.3758  5  good
chromium@413596  188.905  48.908   5  good
chromium@413599  223.345  72.9561  5  good
chromium@413600  192.222  49.3915  5  good
chromium@413601  421.542  18.8244  5  bad    <--
chromium@413602  423.616  11.3958  5  bad
chromium@413614  419.982  10.2067  5  bad

Bisect job ran on: mac_retina_perf_bisect
Bug ID: 642061

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests page_cycler_v2.intl_es_fr_pt-BR
Test Metric: timeToFirstMeaningfulPaint_avg/pcv1-warm/http___www.voila.fr_
Relative Change: 117.62%
Score: 99.5

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_retina_perf_bisect/builds/1698
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9000181246977758880


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

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

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


===== SUSPECTED CL(s) =====
Subject : Fix jank during mac resize
Author  : enne
Commit description:
  
Allow SetNeedsBeginFrames messages to be handled on Mac during resize.
If this message is not handled, then the renderer says that it needs
frames but the message is ignored because of the resize lock.  Then, the
browser never sends begin frame messages and the renderer then never is
able to produce a frame.  This means that it can't produce a frame of
the right size before the resize lock times out and there's jank on
screen.

R=ccameron@chromium.org,sievers@chromium.org
BUG= 632603 ,638561

Review-Url: https://codereview.chromium.org/2246613002
Cr-Commit-Position: refs/heads/master@{#413601}
Commit  : e5ce61d4966237e3572f3048a6ea39c7ba7d7c64
Date    : Tue Aug 23 00:27:11 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@413598  205.796  22.6825  5  good
chromium@413600  189.712  12.4655  5  good
chromium@413601  481.695  11.1567  5  bad    <--
chromium@413602  482.658  9.94625  5  bad
chromium@413605  479.438  14.72    5  bad
chromium@413611  490.448  13.0695  5  bad
chromium@413624  471.389  16.5972  5  bad
chromium@413649  490.981  5.07916  5  bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 642061

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests page_cycler_v2.intl_es_fr_pt-BR
Test Metric: timeToFirstMeaningfulPaint_avg/pcv1-warm/http___www.voila.fr_
Relative Change: 138.58%
Score: 99.9

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


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

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

Enne is this regression expected?

No, it's not expected and is quite surprising.  Thanks for the ping, this fell off my radar.  I'll try to take a look this week.

Still looking into this, but something odd is going on here.  I wouldn't have expected my change to have any effect.  This was originally intended to fix jank when maximizing/resizing the browser and shouldn't affect page load.  It appears that although some pages regressed page load time, in the three cases I looked at, other pages ended up getting faster.

In this report, voila got slower but a bunch of pages got faster: https://chromeperf.appspot.com/report?sid=8820b76aa0240c7846b8ce9cc3fa423eed870f91dc5bf08da1a4fcfa7dccfa09&start_rev=412177&end_rev=415048&rev=413649

Booking.com got slower, but ebay.com got significantly faster: https://chromeperf.appspot.com/report?sid=b95c345116bc15d5d4acf95c137f53ba56e504e3543ac5a3659ae8beb62f0b10&rev=413631

farsnews got slower, but google got faster: https://chromeperf.appspot.com/report?sid=edad496b45dc34fb05bf56d5c920607eb01d7c2c95912df61fa5522d959c0cce&rev=413614

Am going to keep looking into this, but just wanted to note that.

I am not able to repro this locally.  Looking at https://chromeperf.appspot.com/report?sid=8820b76aa0240c7846b8ce9cc3fa423eed870f91dc5bf08da1a4fcfa7dccfa09&start_rev=412177&end_rev=415048&rev=413649 locally yields me the image below.  "tot" is with my patch applied at r425087 and "revert" is with it reverted on top of r425087.  I ran it 10 times for each page (on the last two runs), which yields a good bit of variance on this page, for whatever reason.  Other pages seem a bit more stable.

It looks like with and without my patch I see times similar to both the before and after times.  There's a "fast" ToT and a "slow" ToT and a "fast" revert and a slow "revert" and the variance when running ten runs, which seems to encompass that whole range of values.

I'm inclined to believe that this page is just particularly sensitive to timings and that my page didn't make this extensively worse and just happened to slightly push it over a performance cliff on the bots.

Re: pagecycler_v2_mobile.  yahoo got slower, but the page load times improved overall and many pages got faster: https://chromeperf.appspot.com/report?sid=d3fed83b5de83bc796466d7289c27f6d562a145e95bb1eaae57185be74036178&start_rev=412473&end_rev=418096&rev=413617

My change allows the browser to know that the renderer needs frames during resize.  If this slight bit of extra work affects pages that dramatically, then the benchmark is too sensitive.  In general, it also appears that my change was a net win on the bots.

I'm going to WontFix this.