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

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


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

android-nexus9

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

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


===== SUSPECTED CL(s) =====
Subject : DrawingBuffer: Clean up GL state restoration
Author  : ccameron
Commit description:
  
Several of DrawingBuffer's methods leave the caller's state dirty,
and the responsibility for restoring this state comes in three forms:
- Responsibility of DrawingBuffer.
  - E.g, DrawingBuffer::PrepareTextureMailbox, which calls
    DrawingBuffer::finishPrepareTextureMailboxGpu, which restores
    texture and framebuffer bindings.
- Responsibility of the caller
  - E.g, WebGLRenderingContextBase::restoreStateAfterClear and
    everything that calls it.
  - Except..
- Both, together, in strange ways. That is, the caller will explicitly
  restore some state, but it will also call into DrawingBuffer to
  restore some of the state
  - E.g, WebGLRenderingContextBase::reshape, where we have all
    sorts of state restore calls, from all sorts of places.

Note how strange it is to have WebGLRenderingContextBase call
DrawingBuffer to have it restore state. WebGLRenderingContextBase is
the structure that knows the values to restore -- DrawingBuffer only
knows these values because WebGLRenderingContextBase told them to it.

Get rid of all of the state tracking in DrawingBuffer. Instead, have
it call back to its Client (WebGLRenderingContextBase) to restore state
at the end of all of its public entrypoints.

There exists no testing for this state restoration. Sprinkle "verify
that state was restored correctly" calls throughout the existing tests.

Also, make some method names more sensical. Change "commit" to a
name that reflects what it does and the state changes associated with it.
Change "reset" to "resize".

BUG= 648707 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel

Review-Url: https://chromiumcodereview.appspot.com/2402273002
Cr-Commit-Position: refs/heads/master@{#426686}
Commit  : 123016bf9ed08d599540dddc9a3b92a0df7eba2e
Date    : Fri Oct 21 02:07:29 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@426627  1802240  0.0      5  good
chromium@426664  1806336  0.0      5  good
chromium@426682  1806336  0.0      5  good
chromium@426685  1806336  0.0      5  good
chromium@426686  1818624  0.0      5  bad    <--
chromium@426687  1818624  0.0      5  bad
chromium@426691  1818624  0.0      5  bad
chromium@426700  1822720  0.0      5  bad

Bisect job ran on: android_nexus9_perf_bisect
Bug ID: 659068

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile
Test Metric: memory:chrome:all_processes:reported_by_os:system_memory:ashmem:proportional_resident_size_avg/background/after_https_mobile_twitter_com_justinbieber_skip_interstitial_true
Relative Change: 1.14%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus9_perf_bisect/builds/2213
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8997836019631144608


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

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