Open Bug 1350207 Opened 4 years ago Updated 4 years ago
Label the PVRManager message
VRManagerChild doesn't belong to any tab or document, it is bound with process like CompositorBridgeChild. We need a mechanism to label messages with different EventTarget before start to do this labeling work.
Whiteboard: [QDL][BACKLOG][GFX] → [QDL][BACKLOG][GFX][gfx-noted]
This is rather high up there on the list of top unlabelled runnables which seems odd to me. Is there a chance it's running when there's no VR hardware or in a non-VR context?
(In reply to Andrew Overholt [:overholt] from comment #1) > This is rather high up there on the list of top unlabelled runnables which > seems odd to me. Is there a chance it's running when there's no VR hardware > or in a non-VR context? Specifically PVRManager::Msg_UpdateDisplayInfo?
(In reply to Andrew Overholt [:overholt] from comment #1) > This is rather high up there on the list of top unlabelled runnables which > seems odd to me. Is there a chance it's running when there's no VR hardware > or in a non-VR context? The PVRManager UpdateDisplayInfo message will only be fired if a user visits a WebVR page. If they have no VR hardware present, the message with fire just once (updating the content process with the results of Navigator.GetVRDisplays()). If VR hardware is present and the user visits a WebVR site, this message will fire continuously, at 90hz, to update the content process of sensor inputs, 3d tracking information, and vr device status. Although a smaller portion of users will be accessing WebVR sites with VR hardware, perhaps this runnable shows up proportionally higher due to it being called at 90hz for the duration of the WebVR sessions. We wish to update the sensory data at about 900hz (10 times per frame, to enable sub-frame 3d pose prediction updates); however, before this occurs we will change the IPC mechanism for this data to use a lock-free data structure that is in a shared mmap between the processes (Bug 1346927). This is planned for the FF57/58 timeline and will follow remoting of the VRManagerParent to it's own process, which will be spawned on-demand (Bug 1362578). I hope this helps!
OK. It would be nice to confirm somehow with telemetry that this really only does happen for users with VR hardware who are visiting VR-enabled websites. If that's true, then we probably don't need to label it.
I just checked our telemetry. Out of 246055 sessions, 242902 of them never saw a PVRManager::Msg_UpdateDisplayInfo message. I see similar numbers for PVRManager::Msg_GamepadUpdate. Since this is a message that only a small percentage of our users see, I think we can ignore it for now.
You need to log in before you can comment on or make changes to this bug.