Skip to content
This repository has been archived by the owner on Apr 4, 2018. It is now read-only.

State and events for interstitial/warning screens #34

Closed
brianchirls opened this issue May 19, 2016 · 3 comments
Closed

State and events for interstitial/warning screens #34

brianchirls opened this issue May 19, 2016 · 3 comments

Comments

@brianchirls
Copy link

Over at webvr-polyfill, there's been a request for events that would fire when the Cardboard interstitial appears and disappears. I think I read @toji say somewhere that the interstitial would be built into Chrome on Android. It occurs to me that this is analogous to the Oculus safety screen and that it would be useful to know when these screens are blocking the display so the user doesn't miss any content.

Does anybody know if the Oculus SDK allows detection of this sort of thing?

It seems that there should be a boolean property on the VRDisplay that tells whether the screen is blocked by a warning and an event that fires when this property changes. Maybe something analogous to document.hidden. Alternatively, onvrdisplaypresentchange could wait to fire until the interstitial is cleared, but that might not make sense if different platforms vary enough in their behavior. For example, if Chrome/Android/Cardboard (or the polyfill) shows an interstitial when you tilt the device too close to vertical, then the latter approach wouldn't work.

I could imagine platforms in the future popping up warnings for various safety and comfort reasons, like: an epilepsy blocker if it detects bright flashing light, or an interruption if the frame rate drops too low.

@toji
Copy link
Collaborator

toji commented May 19, 2016

For the Oculus SDK I believe that any time the app isn't showing what it's rendering (whether due to the HSW or Unknown Sources screen or because Oculus Home is visible) ovr_SubmitFrame will return ovrSuccess_NotVisible. Not terribly granular, but it gives us something to work with. My first thought would be to not resolve the requestPresent promise until this starts returning ovrSuccess. (And have it submit dummy frames periodically in the background till then to test.) Maybe if it starts returning that after requestPresent has resolved we could knock down the rate that VRDisplay.requestAnimationFrame is called at to avoid spinning our wheels unnecessarily.

Same could go for the polyfill. Don't resolve the promise until the interstitial is ready to disappear.

@brianchirls
Copy link
Author

Sounds like a good start. I don't think slowing the frame rate is sufficient, since you may want to fully pause the experience. But we could start with this and then add in additional state and events later on if the need arises. Right?

@cvan
Copy link
Contributor

cvan commented Jun 2, 2016

Moved to immersive-web/webxr#42

@cvan cvan closed this as completed Jun 2, 2016
@MozillaReality MozillaReality locked and limited conversation to collaborators Jun 2, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants