New issue
Advanced search Search tips

Issue 610720 link

Starred by 0 users
Status: Duplicate
Merged: issue 604007
Owner:
tdres...@chromium.org
Closed: May 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

52.2%-63.5% regression in smoothness.pathological_mobile_sites at 385442:387812

Project Member Reported by tdres...@chromium.org, May 10 2016 
See the link to graphs below.

Comment 1 by tdres...@chromium.org, May 10 2016 

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

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


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

android-nexus7v2
android-nexus9
Project Member

Comment 2 by 42576172...@developer.gserviceaccount.com, May 11 2016

Mergedinto: 604007
Status: Duplicate (was: Assigned)

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


===== SUSPECTED CL(s) =====
Subject : Hook up ui::Compositor to Display's BeginFrameSource
Author  : enne
Commit description:
  
This hooks up the first SurfaceFactoryClient to the real
BeginFrameSource owned by the OnScreenDisplayClient.  This is done by
adding an OutputSurfaceClient::SetBeginFrameSource method.  As the
SurfaceDisplayOutputSurface is also a SurfaceFactoryClient, it can hand
the real begin frame source directly to ui::Compositor's scheduler.

This allows the removal of some of the browser vsync plumbing, but not
all of it.  Once the renderer compositors have been hooked up to use
this path as well, then this and all of the VSyncObserver code can be
ripped out.

The BeginFrameSource is created by the BrowserCompositorOutputSurface
which updates it based on vsync information that it receives.  This
BeginFrameSource is passed to the Display (via OutputSurfaceClient),
which informs the SurfaceManager that the compositor using
that Display should be driven by that BeginFrameSource.  The
SurfaceManager then informs the SurfaceDisplayOutputSurface about
the BeginFrameSource, which passes it into the single thread proxy's
cc::Scheduler for that ui::Compositor's instance.  Plumbing!

The path from SurfaceManager to SurfaceDisplayOutputSurface was
added in https://codereview.chromium.org/1673783004, but the rest
of the plumbing is new to this patch.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1821863002

Cr-Commit-Position: refs/heads/master@{#387228}
Commit  : 19c108580b99c469ed192066310e3162bf8c196e
Date    : Thu Apr 14 03:37:18 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@386352  9.11436  0.429443  5  good
chromium@386888  8.89226  0.517358  5  good
chromium@387156  8.43592  0.224773  5  good
chromium@387223  8.94108  0.482772  5  good
chromium@387226  8.85696  0.241997  5  good
chromium@387227  8.88202  0.516983  5  good
chromium@387228  13.0648  0.344405  5  bad    <--
chromium@387232  13.2031  0.336427  5  bad
chromium@387240  13.4774  0.582018  5  bad
chromium@387257  13.2989  0.420889  5  bad
chromium@387290  12.7642  0.587648  5  bad
chromium@387424  13.3692  0.697368  5  bad

Bisect job ran on: android_nexus7_perf_bisect
Bug ID: 610720

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.pathological_mobile_sites
Test Metric: mean_input_event_latency/mean_input_event_latency
Relative Change: 46.68%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_perf_bisect/builds/2972
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9013035725868994160


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

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

Comment 3 by 42576172...@developer.gserviceaccount.com, May 11 2016 


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


===== SUSPECTED CL(s) =====
Subject : Hook up ui::Compositor to Display's BeginFrameSource
Author  : enne
Commit description:
  
This hooks up the first SurfaceFactoryClient to the real
BeginFrameSource owned by the OnScreenDisplayClient.  This is done by
adding an OutputSurfaceClient::SetBeginFrameSource method.  As the
SurfaceDisplayOutputSurface is also a SurfaceFactoryClient, it can hand
the real begin frame source directly to ui::Compositor's scheduler.

This allows the removal of some of the browser vsync plumbing, but not
all of it.  Once the renderer compositors have been hooked up to use
this path as well, then this and all of the VSyncObserver code can be
ripped out.

The BeginFrameSource is created by the BrowserCompositorOutputSurface
which updates it based on vsync information that it receives.  This
BeginFrameSource is passed to the Display (via OutputSurfaceClient),
which informs the SurfaceManager that the compositor using
that Display should be driven by that BeginFrameSource.  The
SurfaceManager then informs the SurfaceDisplayOutputSurface about
the BeginFrameSource, which passes it into the single thread proxy's
cc::Scheduler for that ui::Compositor's instance.  Plumbing!

The path from SurfaceManager to SurfaceDisplayOutputSurface was
added in https://codereview.chromium.org/1673783004, but the rest
of the plumbing is new to this patch.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1821863002

Cr-Commit-Position: refs/heads/master@{#387228}
Commit  : 19c108580b99c469ed192066310e3162bf8c196e
Date    : Thu Apr 14 03:37:18 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@386352  8.9986   1.57152   5  good
chromium@387082  7.556    0.198891  5  good
chromium@387174  8.1542   0.713296  5  good
chromium@387220  8.2464   1.16453   5  good
chromium@387226  7.9624   0.646687  5  good
chromium@387227  8.3722   2.03827   5  good
chromium@387228  14.9016  1.1396    5  bad    <--
chromium@387229  15.4432  2.26166   5  bad
chromium@387232  14.8604  0.927247  5  bad
chromium@387243  16.2538  1.89758   5  bad
chromium@387265  15.2656  1.29626   5  bad
chromium@387447  15.8216  2.10367   5  bad
chromium@387812  15.666   0.809334  5  bad

Bisect job ran on: android_nexus7_perf_bisect
Bug ID: 610720

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.pathological_mobile_sites
Test Metric: mean_input_event_latency/http___www.pbs.org_newshour_bb_much-really-cost-live-city-like-seattle__the-rundown
Relative Change: 74.09%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_perf_bisect/builds/2973
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9013035670905765248


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

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

Sign in to add a comment