New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 718246 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug
Proj-XR


Show other hotlists

Hotlists containing this issue:
VR-Automated-Tests


Sign in to add a comment

WebVR: Do not fire window.requestAnimationFrame while presenting on Android

Project Member Reported by ddorwin@chromium.org, May 4 2017

Issue description

[This is the opposite of  issue 704341  and reflects a change in desired behavior on Android.]

The consensus seems to be that window.requestAnimationFrame should be tied to page visibility. [1]

Thus, we should not fire window.requestAnimationFrame on Android when WebVR is presenting. This may cause issues for some sites or libraries. Those will need to be fixed.

[1] https://github.com/w3c/webvr/issues/225#issuecomment-298778492 as well as internal discussions.
 
Labels: -M-60
Labels: -Pri-3 M-61 Pri-2
Cc: mscales@chromium.org meganlindsay@chromium.org
This may affect some apps. As such, we should do it early in the milestone. We should also reach out to those that were affected last time rAF was not fired on Android. This includes threejs, which is mentioned in  issue 704341 .
Cc: ricardocabello@google.com
+ricardocabello for the ThreeJS question.

This will cause a whole bunch of subtle bugs, I think. For many people their loop looks something like:

function main() {
  if (display.isPresenting) {
    ...
    display.requestAnimationFrame(main);
  } else {
    ...
    window.requestAnimationFrame(main);
  }
}

This gives you one frame after entering presentation mode where you are driving the VR loop from a window rAF, which I assume will no longer be fired. I imagine this just kills the loop altogether.

Developers should, of course, cancel the rAF when they begin/end presenting and call the correct one, but due to being *very slightly* more complicated, I wonder if many people currently do it correctly.
We actually handle this case explicitly, by manually firing a single extra window rAF after presentation starts.

Should this be part of the spec? Other implementers may have different behavior here in the future. Or does the 2.0 spec address this somehow?
Megan, what's the next step here?
Labels: -Pri-2 -M-61 M-62 Pri-1
Cc: klausw@chromium.org
Owner: ----
Status: Available (was: Assigned)
I believe this is just a matter of reverting the CL in  issue 704341  (and verifying behavior). It doesn't revert cleanly, but it is small.
Owner: cjgrant@chromium.org
Status: Started (was: Available)
Project Member

Comment 10 by bugdroid1@chromium.org, Aug 24 2017

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

commit 1b6a5e96191538ad8a4e0918a14b8724016b4d27
Author: Christopher Grant <cjgrant@chromium.org>
Date: Thu Aug 24 14:19:08 2017

VR: Do not fire window.rAF while presenting

As per the associated bug, we're reverting an extra call to
window.requestAnimaionFrame. Separate code already triggers a rAF when
presentation starts.

BUG= 718246 

Change-Id: I5bf961749d80476572f1610a3992e62a4e6a5301
Reviewed-on: https://chromium-review.googlesource.com/628963
Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Christopher Grant <cjgrant@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497034}
[modify] https://crrev.com/1b6a5e96191538ad8a4e0918a14b8724016b4d27/third_party/WebKit/Source/modules/vr/VRDisplay.cpp

Status: Fixed (was: Started)
Components: Blink>WebXR

Sign in to add a comment