Closed Bug 1390616 Opened 2 years ago Closed Last year

WebVR with SteamVR severely effects the performance of all Firefox tabs/windows

Categories

(Core :: WebVR, defect, P1)

55 Branch
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox57 --- wontfix
firefox58 --- affected

People

(Reporter: darktech, Unassigned)

References

Details

Attachments

(1 file)

428.80 KB, application/json
Details
User Agent: Mozilla/5.0 (Linux; Android 7.1.2; Nexus 6P Build/N2G48B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36

Steps to reproduce:

Installed FF 55.0.1, latest Nvidea drivers, Steam (and StreamVR) and RiftCat.
Navigate to one of the examples on https://aframe.io

Note: RiftCat registers the fact that you own a Vive (it does not need to running to reproduce the issue, the fact that SteamVR opens automatically is enough: it will report that the Vive is currently disconnected)



Actual results:

All scroll, click, JS events in all tabs (across all windows) will now begin to lag.


Expected results:

Preferably nothing: the fact that a VR headset wasn't connected should have signaled to Firefox that there's no headset and the WebVR should have backed off. Performance degradation shouldn't be experienced, especially across tabs/windows.
Component: Untriaged → WebVR
Product: Firefox → Core
Attached file ff_crash.json
Comment on attachment 8897557 [details]
ff_crash.json

This stack trace was probably unrelated to the performance issue, but contains a lot more detail about my environment.
I have reproduced this.  It appears to be caused by the blocking nature of OpenVR calls that get the headset pose even when not rendering VR frames.

This will be solved by moving our VR frame submission and rendering code to its own process (Just own thread for OSX and Linux).

Once Bug 1362578 has landed with the out-of-process VR support (scheduled for FF58), we should re-test this and ensure that scrolling and other activity is not affected by VR activity.
Depends on: 1362578
Priority: -- → P1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Too late to fix in 57, maybe best to move this work out to 59 or maybe 58 if it's fixed early in beta 58
VR frame submission, sensor polling, and rendering have been moved into the VRService thread, and should no longer be blocking the compositor.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.