Is this for WebVR, VR shell, or both?

We'll need to track both webvr and vrshell. We probably also need to track update rate of contents when they're hosted within vrshell.

Suggest that we break out three separate bugs for this.

For VrShell performance metrics, we can reuse existing smoothness benchmark(https://cs.chromium.org/chromium/src/tools/perf/benchmarks/smoothness.py?q=smoothness.py+package:%5Echromium$&l=1) to measure scrolling experience for VR, and some of smoothness metrics (https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/web_perf/metrics/smoothness.py?q=smoothness.py+package:%5Echromium$&dr) may be reusable for VR. 

For WebVR performance test, since Klaus  added tracing to track fps and frame time, we can implement Telemetry tests to measure fps and frame time for WebVr.

We had meeting with tdresser@ this morning and figured out the draft plan about how to reuse existing smoothness benchmark to measure scrolling performance for Chrome VR.
1. We need to develop our own way to simulate scrolling in VR, the current solution to use gpubenchmarking script to scroll page is not suitable for Chrome VR, since the input pipeline is different.

We will somehow inject gesture data into VrController(https://cs.chromium.org/chromium/src/chrome/browser/android/vr_shell/vr_controller.cc?l=249) to simulate scrolling, VrShellGl::HandleControllerInput is called once every frame and pull the controller data from VrController.

2. We need to hook up two trace events into our rendering pipeline INPUT_EVENT_LATENCY_ORIGINAL_COMPONENT and INPUT_EVENT_GPU_SWAP_BUFFER_COMPONENT, so we can measure e2e latency for scrolling. INPUT_EVENT_LATENCY_ORIGINAL_COMPONENT should be added when VrController detects gestures. INPUT_EVENT_GPU_SWAP_BUFFER_COMPONENT will probably be added before we send frame to GVR.

3. Run perf test in lab and reuse existing smoothness metrics to calculate latency.

 Issue 715610  has been merged into this issue.

Closing this in favor of more targeted bugs.