New issue
Advanced search Search tips

Issue 734208 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Task
Proj-XR

Blocked on:
issue 734747


Show other hotlists

Hotlists containing this issue:
VR-Automated-Tests


Sign in to add a comment

WebVR: Add automated test to catch regression of 724261

Project Member Reported by bsheedy@chromium.org, Jun 16 2017

Issue description

Now that the issue of window.requestAnimationFrame and VRDisplay.requestAnimationFrame not always being equivalent should be fixed, we should add a test to make sure it doesn't regress in the future.

I don't think there's any guarantee about which callback will be called first, so our best bet might be to:

1. Register callbacks for each rAF that append the current time to an array when run (e.g. windowTimes and vrdisplayTimes)
2. Let the page sit for a sufficient amount of time, e.g. 1 second
3. assert that windowTimes[i] ~= vrdisplayTimes[i] for each element, say within 1ms of each other
 
Blockedon: 734747
Components: Internals>VR
Status: Available (was: Untriaged)
Owner: mthiesse@chromium.org
Status: Started (was: Available)
I think I know what was causing this test to be difficult to write, will take a stab at it.
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 28 2017

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

commit af0e7a54376b11198f971255b92b2ee4a24f34e2
Author: Michael Thiessen <mthiesse@chromium.org>
Date: Tue Nov 28 01:11:00 2017

WebVR: Fire display rAF synchronously with window rAF for magic window

We were posting display rAF for magic window when there was no reason
to, which was making comparing window rAF and display rAF performance
difficult. This CL fixes that, and adds a test to make sure display
rAF is equivalent to window rAF in terms of scheduling.

This exposes the same race in getFrameData_oneframeupdate.html that was
found in WebVrTabTest#testPoseDataUnfocusedTab, namely that the pose
can start off being null, racily. The previous behavior of posting the
vrDisplay rAF was hiding this.

Bug:  734747 ,  734208 , 787196
Change-Id: Ib6b657b1966359683b3c7aca16be26be9c3c54dd
Reviewed-on: https://chromium-review.googlesource.com/788240
Commit-Queue: Michael Thiessen <mthiesse@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519501}
[add] https://crrev.com/af0e7a54376b11198f971255b92b2ee4a24f34e2/third_party/WebKit/LayoutTests/vr/VRDisplay_rAF_fires_with_window_rAF.html
[modify] https://crrev.com/af0e7a54376b11198f971255b92b2ee4a24f34e2/third_party/WebKit/LayoutTests/vr/getFrameData_oneframeupdate.html
[modify] https://crrev.com/af0e7a54376b11198f971255b92b2ee4a24f34e2/third_party/WebKit/Source/modules/vr/VRDisplay.cpp

Status: Fixed (was: Started)
Labels: M-64 Test-Complete
Components: Internals>XR
Components: Blink>WebXR

Sign in to add a comment