1480808 - VRDisplayHost queue causes delay when entering WebVR

Status: RESOLVED FIXED

(Core :: WebVR, defect, P3)

Description

[Imanol Fernandez]

Some demos have a noticeable delay when entering WebVR on Android (via Firefox Reality). 

STR:
* Open https://developer.playcanvas.com/en/tutorials/webvr-lab/ in FxR
* Click Enter VR
* There is a noticeable delay until the first frame is submitted

Did some research on GV code and found that VRDisplayHost::SubmitFrame() call exits a lot of times because aFrameId and mDisplayInfo.mFrameId don't match

> // Ensure that we only accept the first SubmitFrame call per RAF cycle.
> if (!mFrameStarted || aFrameId != mDisplayInfo.mFrameId) {
>  return;
> }

The problem I see is that when a WebVR frame (the first frame in the STR example) takes a longer time than the default threshold (50ms), Gecko watchdog starts to generate new VR frames by calling NotifyVRVsync, which increases the frame number in VRDisplayHost::StartFrame. Because of that, later a ton of WebGL frames are rendered but not submitted (more than 100 frames in the STR example) until the WebGL frame catches up the VRDisplayHost::StartFrame() counter, which was way ahead. This was useful in desktop to e.g. prevent kick offs from Oculus Rift/Vive but not sure if it is helping in mobile.

I tried to increase the watchdog maxRAF threshold to 500/1000 and EnterVR is much faster. But this causes a delay on the first frame on demos that were quick to enter (e.g. WebVR sample). It seems that something in the code is using the maxRAF value to trigger the first VR frame.

Could VRDisplayHost jump to the most recent frame to render instead of running all the queue of RAFs that will never get submitted? The delay is very noticeable in mobile. On desktop it probably is faster because of the more powerfull hardware.

Comment 1

[Daosheng Mu[:daoshengmu]]

It seems like WebVR in immersive mode for desktop headsets, we need 90 HZ, so we queue the frames if the framerate is faster than 90 in RAFs. Does GVR immersive mode is max at 60 HZ? If so, we probably don't need to queue frames on mobile because Vsync is already 60HZ. We can do an adjustment on the preference, https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/modules/libpref/init/all.js#5313.

Comment 2

[:kip (Kearwood Gilbert)]

We can certainly adjust this value for mobile; however, I would suggest not increasing it past 50ms on Desktop.

An even better solution would be to have an incremental timeout for mobile:

- If a frame takes longer than 50ms, the watchdog queues a new one and reset the timer to 100ms.
- If the watchdog queued frame takes longer than 100ms, queue a new one and reset the timer to 200ms.
- If the second queued watchdog frame takes longer than 200ms, queue a new one and reset the timer to 400ms.
- If the third queued watchdog frame takes longer than 400ms, queue a new one and reset the timer to 800ms.
And so on...

Once a frame has been submitted, and it is the next frame we need to render, we can reset the value back to 50ms and return to the normal render loop.

While the watchdog is active with this loop, we should probably show something else to the user, like a busy or loading indicator.

Comment 3

[:kip (Kearwood Gilbert)]

Could you confirm if this is still occurring?

If so, we can make an adjustment after landing refactoring in Bug 1473402

Comment 4

[Imanol Fernandez]

This was already fixed in Bug 1482613