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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvtfFtwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_tCVrQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_vHHogoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_uqBrgoM


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

android-nexus5
android-nexus7v2

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

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

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


===== SUSPECTED CL(s) =====
Subject : Expose if we are using swiftshader via WebGraphicsContext3DProvider.
Author  : danakj
Commit description:
  
When we are using swiftshader, we are able to make contexts but the
compositor will not use GPU compositing, and WebGL/Canvas should not
be producing GL outputs for it. This is visible via the GPUInfo's
software_rendering flag. Currently WebGL and Canvas get this info
via two different paths, and the compositor makes its decision via
a third. They all end up being the same thing (mostly not racey) but
we can make this more common by just having them all check
|software_rendering|.

This has the additional benefits that:
1) We don't need to do a round trip thru the compositor thread to
determine if we're doing GPU compositing (no more RendererCapability
needed).
2) We don't need a separate method on the Platform API.
3) Canvas2D doesn't have a semi-racey thing where it can check
|software_rendering| on one GpuChannelHost, lose it, then make a
context on a different GpuChannelHost. Now the capability is explicitly
tied to the lifetime of the context, which is what the comment in
Platform tried to warn about.
4) Additionally, have DrawingBuffer check lost context and not try
to produce frames in this scenario since it may end up producing the
wrong mode for the compositor which is already using a new context
with a different mode. (Canvas already does this.)

This helps us eliminate races between cc/webgl/canvas on
making this decision. When the GpuChannelHost is lost, all contexts
become lost when the next code tries to create a context. Since we
now tie the decisions around which mode to use to the context, and
the context is lost when any other part of the system would change
its opinion about what mode to use, they should all agree.

R=junov@chromium.org, kbr@chromium.org, piman@chromium.org
BUG= 606056 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2267993002
Cr-Commit-Position: refs/heads/master@{#413837}
Commit  : 4dd43951b9efedb9473e65e8132ee5d8976bc860
Date    : Tue Aug 23 21:20:36 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@413834  5606888  0.0      5  good
chromium@413836  5646210  87925.8  5  good
chromium@413837  7704040  0.0      5  bad    <--
chromium@413840  7740740  89571.3  5  bad
chromium@413846  7704040  0.0      5  bad
chromium@413858  7704040  0.0      5  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 642126

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests memory.top_10_mobile_stress
Test Metric: foreground-memory:chrome:all_processes:reported_by_chrome:gpu:effective_size_avg/http_m_youtube_com_results_q_science
Relative Change: 37.40%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4064
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9002960891250437824


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

| 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 : Expose if we are using swiftshader via WebGraphicsContext3DProvider.
Author  : danakj
Commit description:
  
When we are using swiftshader, we are able to make contexts but the
compositor will not use GPU compositing, and WebGL/Canvas should not
be producing GL outputs for it. This is visible via the GPUInfo's
software_rendering flag. Currently WebGL and Canvas get this info
via two different paths, and the compositor makes its decision via
a third. They all end up being the same thing (mostly not racey) but
we can make this more common by just having them all check
|software_rendering|.

This has the additional benefits that:
1) We don't need to do a round trip thru the compositor thread to
determine if we're doing GPU compositing (no more RendererCapability
needed).
2) We don't need a separate method on the Platform API.
3) Canvas2D doesn't have a semi-racey thing where it can check
|software_rendering| on one GpuChannelHost, lose it, then make a
context on a different GpuChannelHost. Now the capability is explicitly
tied to the lifetime of the context, which is what the comment in
Platform tried to warn about.
4) Additionally, have DrawingBuffer check lost context and not try
to produce frames in this scenario since it may end up producing the
wrong mode for the compositor which is already using a new context
with a different mode. (Canvas already does this.)

This helps us eliminate races between cc/webgl/canvas on
making this decision. When the GpuChannelHost is lost, all contexts
become lost when the next code tries to create a context. Since we
now tie the decisions around which mode to use to the context, and
the context is lost when any other part of the system would change
its opinion about what mode to use, they should all agree.

R=junov@chromium.org, kbr@chromium.org, piman@chromium.org
BUG= 606056 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2267993002
Cr-Commit-Position: refs/heads/master@{#413837}
Commit  : 4dd43951b9efedb9473e65e8132ee5d8976bc860
Date    : Tue Aug 23 21:20:36 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@413834  5606888  0.0      5  good
chromium@413836  5606888  0.0      5  good
chromium@413837  7701418  5862.08  5  bad    <--
chromium@413838  7704040  0.0      5  bad
chromium@413842  7704040  0.0      5  bad
chromium@413850  7704040  0.0      5  bad
chromium@413866  7704040  0.0      5  bad
chromium@413898  7743362  87925.8  5  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 642126

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests memory.top_10_mobile_stress
Test Metric: foreground-memory:chrome:all_processes:reported_by_chrome:gpu:effective_size_avg/http_m_youtube_com_results_q_science
Relative Change: 38.10%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4065
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9002960842958941376


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

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