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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqv6T8AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgyuz9nwgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqqTy_QkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqtTVtgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgyqWcuQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqpnn_QoM


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/8979926159300673376

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

Hi ccameron@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : ccameron
  Commit : 0226fbeb21522a77293fa4f956ec8c8165ee7584
  Date   : Tue May 09 14:55:47 2017
  Subject: Wait for a frame before white-out for 167 instead of 50 msec

Bisect Details
  Configuration: mac_10_11_perf_bisect
  Benchmark    : page_cycler_v2.intl_ko_th_vi
  Metric       : timeToFirstMeaningfulPaint_avg/pcv1-cold/http___www.chosun.com_
  Change       : 46.90% | 316.224666666 -> 464.518666667

Revision             Result                  N
chromium@470292      316.225 +- 59.6811      9      good
chromium@470315      315.54 +- 41.756        6      good
chromium@470326      313.344 +- 48.1423      6      good
chromium@470329      313.948 +- 49.5426      6      good
chromium@470330      476.036 +- 80.0989      6      bad       <--
chromium@470331      446.677 +- 163.481      6      bad
chromium@470332      484.749 +- 107.06       6      bad
chromium@470337      444.201 +- 113.755      6      bad
chromium@470381      464.519 +- 209.049      9      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...www.chosun.com. page_cycler_v2.intl_ko_th_vi

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

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


| 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 see that the benchmark increased by (446 - 313) ~= (167 - 50), which is the timeout delta.

If this timeout is affecting a benchmark, then I very strongly suspect that the benchmark is measuring something that is not meaningful. If this does indicate a problem, the problem is much deeper and more complex than just the timeout value.

Does this benchmark have an owner who understands what it is measuring and how?

Explictly assigning. A CL you landed tripped one of the speed metrics we measure in the lab. If this is the first time this has happened to one of your CLs, or if it's been a while, please read: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/addressing_performance_regressions.md

We're looking for one of the following:
1. Justification via explanation
2. Plan to revert or fix
3. Angry rage throwing of equipment at my head

Just be aware that I'm trained in trumpet playing and First Aid and am not afraid to use it.

Note: This was a bulk edit message and not very personal.

See #4

Assigning to benchmark owner kouhei to answer the questions in #4, sorry for the slow response! Also cc tdresser for the metrics.

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

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

Hi ccameron@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : ccameron
  Commit : 0226fbeb21522a77293fa4f956ec8c8165ee7584
  Date   : Tue May 09 14:55:47 2017
  Subject: Wait for a frame before white-out for 167 instead of 50 msec

Bisect Details
  Configuration: mac_10_11_perf_bisect
  Benchmark    : page_cycler_v2.intl_ko_th_vi
  Metric       : timeToFirstMeaningfulPaint_avg/pcv1-cold/http___www.chosun.com_
  Change       : 52.18% | 316.267 -> 481.281166667

Revision             Result                  N
chromium@470299      316.267 +- 45.5353      6      good
chromium@470315      320.053 +- 48.7619      6      good
chromium@470323      318.947 +- 59.1306      6      good
chromium@470327      315.849 +- 36.4575      6      good
chromium@470329      318.63 +- 45.2541       6      good
chromium@470330      481.281 +- 77.5353      6      bad       <--

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...www.chosun.com. page_cycler_v2.intl_ko_th_vi

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8972516947082612192


For feedback, file a bug with component Speed>Bisection

470329 good trace permalink: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-07-31_23-23-33-11279.html
470330 bad trace permalink: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-07-31_22-36-14-30427.html

The CL does seem to be changing when BeginMainFrame is scheduled for the first time.

I'm not super familiar w/ the cc scheduler why this changes BeginMainFrame timings.
Metric wise this looks like a real regression to me and I don't have a good explanation of this.

ccameron; Would you mind taking a look at the trace?

Perf sheriff checking in: ccameron, any update?

ccameron: another perf sheriff ping. did you have a chance to look at the trace from #13?

Brian or Enne, any thoughts on why this appears to change BeginMainFrame timings?

I think ccameron explains what's going on here in comment #4, and I also agree with what kouhei says in comment #12 as to why this patch affected this measurement.

This patch increases the time for to wait for the renderer to produce the first frame to avoid whiteouts.  If the benchmark was affected by this, then that means that it was putting up blank frames and the benchmark was measuring the wrong thing.

This is not a regression of user experience (unless you are counting putting up blank pages as a positive experience).  My interpretation here is that this should be treated as a new baseline for this benchmark at a minimum.  At worst, this benchmark needs to be adjusted if it is sensitive to whether or not we are showing blank frames to the user.

I think this is either on kouhei to adjust the benchmark or to wontfix if this is expected for what it is measuring.

What is page cycler measuring? I assume it's something sooner than first meaningful paint (which I would not expect to move with this change).

Marking this as WONTFIX. I think its reasonable to have this the new baseline, since ttFMP supercedes ttFCP.