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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=33bca9ad78d9e5994fa1df71a9e1ac9afa1128b8794a30cd85e37696b563114d


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

pixel_xl

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c2646f4e6ddf95a93eaf6a392c21691b6036a2a9

commit c2646f4e6ddf95a93eaf6a392c21691b6036a2a9
Author: bsheedy <bsheedy@chromium.org>
Date: Mon Jun 25 19:13:57 2018

Roll WebXR samples repo revision

Rolls the WebXR samples repo DEPS revision to the most recent commit,
which should have all the fixes necessary to get the XR perf tests
running again.

Bug: 853400
Change-Id: I2327ca1c83cee3f242a0b9cdfb72b14fca09751c
Reviewed-on: https://chromium-review.googlesource.com/1113912
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570124}
[modify] https://crrev.com/c2646f4e6ddf95a93eaf6a392c21691b6036a2a9/DEPS

Should be fixed now, but I'll wait until we start getting results again to be sure.

Getting results now, but everything is suspiciously close to 60 FPS...

Suspicious results seem to be due to the recent change to buffer sizes, causing the scene to render at a lower resolution. I'll get a patch out to increase it to roughly the same size as before.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a0a4bf6ad756368b98b7b33d4a0a7336737dab86

commit a0a4bf6ad756368b98b7b33d4a0a7336737dab86
Author: bsheedy <bsheedy@chromium.org>
Date: Wed Jun 27 18:24:45 2018

Update WebXR framebufferScale in perf tests

Updates the framebufferScale used by WebXR performance tests to
correspond to the recommended scale and the 1:1 pixel mapping scale.

The implementation was changed recently, but these values were not
updated at the same time, causing the perf tests to render WebXR
scenes at significantly lower resolution than before.

Bug: 853400
Change-Id: I247682ea97ac5910d0195fdba1004698c4c0679b
Reviewed-on: https://chromium-review.googlesource.com/1116190
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570846}
[modify] https://crrev.com/a0a4bf6ad756368b98b7b33d4a0a7336737dab86/tools/perf/contrib/vr_benchmarks/webxr_sample_pages.py

The change in frame buffer scale numbers did have an effect, but the FPS is still significantly higher. For example, the autorotate page got ~32 FPS before any of this, but now gets ~48 FPS. Brandon, are we correct to assume that an old scale of 0.7 is approximately equivalent to the new 1.0, and old 1.0 is about equivalent to new 1.4? If so, looks like there's an issue with the implementation somewhere.

The old scale of 0.7 (the default if you didn't put anything in the dictionary) is now equivalent to 1.0 in the new implementation, yes (which, again, is the new default if you don't put anything in the dictionary.) To get the old 1.0 value you'll need to query `XRWebGLLayer.getNativeFramebufferScaleFactor(xrSession)` and pass that in to the dictionary. (On Daydream that will be 1.0/0.7, which ~= 1.4)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f5e1fc4724c9edbb45ce6724bde6acb1f2f2ebde

commit f5e1fc4724c9edbb45ce6724bde6acb1f2f2ebde
Author: bsheedy <bsheedy@chromium.org>
Date: Tue Jul 03 01:37:52 2018

Roll WebXR sample repo

Roll the WebXR sample repo to pick up a framebuffer scale fix.

TBR=bajones@chromium.org

Bug: 853400
Change-Id: Ic6880944037ace9fed199e647c04708aec0851af
Reviewed-on: https://chromium-review.googlesource.com/1123642
Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#572077}
[modify] https://crrev.com/f5e1fc4724c9edbb45ce6724bde6acb1f2f2ebde/DEPS

This is still broken... somehow...

Even after the roll, the 1.4x framebuffer scale is still getting significantly higher FPS than the old 1.0x framebuffer scale, see https://chromeperf.appspot.com/report?sid=2bfde390517ae54bd16371bde3244136b38956659e2b1df8cc619ff77252fe80

Still seeing this now that we're getting perf results again, e.g. the autorotate page is sitting at ~45 FPS when before it was ~30.

Assigning to klausw@ at his request.