New issue
Advanced search Search tips

Issue 734747 link

Starred by 2 users

Issue metadata

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

Blocking:
issue 734208



Sign in to add a comment

Investigate requestAnimationFrame weirdness

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

Issue description

A couple of weird behaviors are showing up when comparing window.requestAnimationFrame and VRDisplay.requestAnimationFrame:

1. We would expect one to be called immediately after the other finishes, e.g. if window.requestAnimationFrame's callback fires first, we would expect VRDisplay's callback to be run almost immediately after. However, there's consistently a 3-4 ms delay between the two, sometimes going up to 7-8 ms instead of the ~1 ms we expect.

2. The order in which the callbacks are run is only mostly consistent. E.g., if window.rAF is fired first, we would expect to see:
window.rAF -> VRDisplay.rAF -> window -> VRDisplay -> ...
This holds true most of the time, but rarely, we see:
window.rAF -> VRDisplay.rAF -> window -> window -> VRDisplay -> ...

It's not clear whether these are actual bugs or wrong assumptions on our part, so we need to investigate further.
 
Labels: -Type-Bug Type-Task
Owner: mthiesse@chromium.org
Status: Started (was: Available)
Project Member

Comment 3 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: Blink>WebXR

Sign in to add a comment