1515490 - WebVR opens "VR Server" repeatedly and stalls the entire browser when no HMD is plugged in

Status: RESOLVED FIXED

(Core :: WebVR, defect, P2)

Description

[Brian Peiris]

Tested in Nightly 66 with SteamVR 1.1.4 installed and no HMD plugged in. 

Load https://webvr.info/samples/03-vr-presentation.html, Nightly starts SteamVR and you can see it open "VR Server" as a sub-process repeatedly in the Task Manager. The entire browser stalls while it's trying to do this.

Comment 1

[Brian Peiris]

Here are profiles taken in Nightly and Stable when visiting a webvr site without an HMD plugged in. The GPU Compositor shows 90% of its time spend in SleepEx while the browser is stalling.

Nightly: https://perfht.ml/2V7vxC5

Stable: https://perfht.ml/2Vaw5a7

Comment 2

[Daosheng Mu[:daoshengmu]]

The reason is it [1] checks if the VR display state is available from the VR backend, otherwise, it will tell the current thread, Compositor thread, to sleep and let other threads take the priority. It seems like not a right way to make the Compositor thread to sleep, even though we land VR process, Bug 1516554, it will still happen because this function is running at the GPU process. We should consider to replace it with a timer thread.



[1] https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/gfx/vr/gfxVRExternal.cpp#677

Comment 3

[Daosheng Mu[:daoshengmu]]

(In reply to Brian Peiris from comment #1)
> Here are profiles taken in Nightly and Stable when visiting a webvr site
> without an HMD plugged in. The GPU Compositor shows 90% of its time spend in
> SleepEx while the browser is stalling.
> 
> Nightly: https://perfht.ml/2V7vxC5
> 
> Stable: https://perfht.ml/2Vaw5a7

The profiler from Stable seems not be able to see what function is the bottleneck. I would suspect it should happen at OpenVR ::vr::VR_Init for asking to launch SteamVR runtime.

Comment 5

[:kip (Kearwood Gilbert)]

While doing refactoring in Bug 1473402 to simplify the code, I have spotted the cause. During enumeraton, we are looping with sleep(0) waiting for a flag signalling that the enumeration has completed. This loop is blocking events in the GPU process. We can fix this after Bug 1473402 lands.

Comment 6

[:kip (Kearwood Gilbert)]

Bug 1473402 has landed (included in the patch for Bug 1466702). The enumeration of devices is now asynchronous an should not freeze the browser.

Comment 7

[:kip (Kearwood Gilbert)]

Further investigation is ongoing on the SteamVR popups, so I will keep this issue open for that part.

Comment 8

[p0larity]

(In reply to :kip (Kearwood Gilbert) from comment #7)

Further investigation is ongoing on the SteamVR popups, so I will keep this issue open for that part.

Kudos! I basically stopped using Firefox at home because of this.

Comment 9

[:kip (Kearwood Gilbert)]

With recent refactoring and implementation of WebVR permission prompts, there are no longer any cases where OpenVR will be initialized without the user's explicit consent.