Closed Bug 1381165 Opened 2 years ago Closed 2 years ago

When VRDisplay.SubmitFrame is called multiple times per RAF cycle, latency accumulates

Categories

(Core :: WebVR, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- fixed
firefox56 --- fixed

People

(Reporter: kip, Assigned: kip)

References

()

Details

Attachments

(1 file)

When a VR experience gets laggy and choppy, it sometimes improves quite a bit when taking your headset off with the Oculus CV1.

When taking the headset off, we effectively "idle" the VR display RAF at 15fps or so.  The VR RAF gets driven by nsRefreshDriver during this period effectively.

Normally, we kick off a new RAF immediately after a successful SubmitFrame call.

If a bug in the Javascript calls submitFrame two times in one RAF callback, it would potentially get two frames rendered and two more RAF cycles queued, resulting in a buildup of latency in the IPC message queues and incorrect timing of the rendering, visible as latency.

This patch ensures that only the first VRDisplay.submitFrame call per VRDisplay RAF callback renders and kicks off the next VR RAF callback.
This is very noticeable with SketchFab's "Lily & Snout" demo.
Assignee: nobody → kgilbert
Attachment #8886718 - Flags: review?(dmu)
Comment on attachment 8886718 [details]
Bug 1381165 - Ensure that only the first VRDisplay.submitFrame call per VRDisplay RAF callback renders and kicks off the next VR RAF callback.

https://reviewboard.mozilla.org/r/157512/#review162734

LGTM. thanks!
Attachment #8886718 - Flags: review?(dmu) → review+
Pushed by kgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a31143203b44
Ensure that only the first VRDisplay.submitFrame call per VRDisplay RAF callback renders and kicks off the next VR RAF callback. r=daoshengmu
https://hg.mozilla.org/mozilla-central/rev/a31143203b44
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Comment on attachment 8886718 [details]
Bug 1381165 - Ensure that only the first VRDisplay.submitFrame call per VRDisplay RAF callback renders and kicks off the next VR RAF callback.

Approval Request Comment
[Feature/Bug causing the regression]:
N/A - New Feature
[User impact if declined]:
During WebVR presentation, performance will degrade over time.  Restarting the experience will restore performance.  Some popular sites, such as Sketchfab.com, implement patterns and accelerate this degradation.
[Is this code covered by automated tests?]:
Yes, the code is hit with our automated reftests and mochitests.
[Has the fix been verified in Nightly?]:
Yes, fix confirmed in Nightly
[Needs manual test from QE? If yes, steps to reproduce]: 
Yes, STR:
- Start the Sketchfab.com "Lily and Snout" WebVR demo with an Oculus CV1 and a GTX 1070 or above:
  https://sketchfab.com/models/618ea0209b1045e89b2c6d2b74d0956e
- Click the "View in VR" icon in the bottom-right corner of the player.
- Expected behavior: The experience should play back in the headset without significant judder and the audio should not cut out or stop playing.
- Without the fix, the performance degrades immediately and the audio will stop playing before the experience completes the first loop.
[List of other uplifts needed for the feature/fix]:
None needed.
[Is the change risky?]:
- Low risk.
[Why is the change risky/not risky?]:
- There are only a few lines changed and they are self contained in a single class used only by WebVR.
[String changes made/needed]:
- N/A
Attachment #8886718 - Flags: approval-mozilla-beta?
Comment on attachment 8886718 [details]
Bug 1381165 - Ensure that only the first VRDisplay.submitFrame call per VRDisplay RAF callback renders and kicks off the next VR RAF callback.

webvr fix, beta55+
Attachment #8886718 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8886718 [details]
Bug 1381165 - Ensure that only the first VRDisplay.submitFrame call per VRDisplay RAF callback renders and kicks off the next VR RAF callback.

check-in needed for beta, thanks!
Attachment #8886718 - Flags: checkin?
Attachment #8886718 - Flags: checkin?
I tested using Fx 55.0b13 and I can still reproduce this issue with Oculus Rift and HTC vive. 
I noticed this latency on https://aframe.io/a-painter/ as well.
I re-tested on Oculus Rift and here are the results:

Firefox 56.0-build 6: 

https://sketchfab.com/models/618ea0209b1045e89b2c6d2b74d0956e
 - could not start the demo in the headset, and on the screen it is painted as some squares ( https://imgur.com/a/nvHSx )

https://aframe.io/a-painter/ 
 - having difficulties starting the demo due to the conflict with the native app 
 - high latency (may be caused by the conflict between the native app and the browser)

Firefox 57.0b3:

https://sketchfab.com/models/618ea0209b1045e89b2c6d2b74d0956e
 - could not start the demo in the headset, and on the screen it is painted as some squares ( https://imgur.com/a/nvHSx )

https://aframe.io/a-painter/ 
 - having difficulties starting the demo due to the conflict with the native app 
 - the latency level is slightly lower
 - bad repainting of the browser on the screen

Firefox 58.a1 ( build ID : ):

https://sketchfab.com/models/618ea0209b1045e89b2c6d2b74d0956e
 - could not start the demo in the headset, and on the screen it is painted as some squares ( https://imgur.com/a/nvHSx )

https://aframe.io/a-painter/ 
 - having difficulties starting the demo due to the conflict with the native app
 - the latency level is almost unnoticeable
You need to log in before you can comment on or make changes to this bug.