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

Status: RESOLVED FIXED

(Core :: WebVR, defect, P1)

Description

[darktech]

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.

Comment 1

[darktech]

Attachment: ff_crash.json

Comment 2

[darktech]

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.

Comment 3

[:kip (Kearwood Gilbert)]

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.

Comment 4

[Liz Henry (:lizzard)]

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

Comment 5

[:kip (Kearwood Gilbert)]

VR frame submission, sensor polling, and rendering have been moved into the VRService thread, and should no longer be blocking the compositor.