
Particularly on Android, when a WebXR Session starts, it renders across the full screen. This can cause the Renderer process to be viewed as unimportant and it can then get backgrounded. However, the Renderer process is exactly what is responsible for providing the content that is now being rendered. This plumbs a new boolean through so that the presence of a WebXR session can elevate the importance of the renderer process similar to how a media stream does. Fixed: 378956985 Change-Id: Iafcc031a9e562d80170d78596db6cdd3c049faa8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6271450 Commit-Queue: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Piotr Bialecki <bialpio@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/main@{#1422782}
XR Browser implementation
For a more high level overview of the entire WebXR stack, please refer to components/webxr.
This folder contains trusted XR code. It is largely responsible for either communicating with other trusted code, or to broker connections and communication between either other trusted code or the renderer process and the various XR device runtimes (which are hosted in a separate process).
The primary entrypoint is the VRServiceImpl
, which
implements the VRService
mojom interface. This service is
responsible for brokering connections between the renderer process and the
device process, both for the sake of starting up an XR Session, as well as
simply querying support for a session. Each browsing context ends up creating
its own VRService
. A VRServiceImpl
instance,
when tracking a session, also leans on code from the ./metrics directory to log
various metrics about that session, both at creation and termination.
The XRRuntimeManager
is a singleton component which
maintains references to BrowserXrRuntime
objects representing
the various devices and/or sensor groups that could back an XR Session. The
XRRuntimeManager
is responsible for tracking the state of
the hardware and aiding the multiple VRServices
with
communicating/tracking this state.
When necessary, XRFrameSinkClient
instances aid communication
with viz for runtimes which utilize that component to manage their own
compositing.
Some chrome-specific customizations based on this content implementation can be found in chrome/browser/vr