1# Overview
2At a high level, AR/VR (collectively known as XR) APIs are wrapped in
3XRRuntimes.
4
5Some XRRuntimes must live in the browser process, while others must not live in
6the browser process.  The ones that cannot live in the browser, are hosted in a
7service.
8
9# Supported Session types
10
11## Magic-window:
12Magic window sessions are requested by sites that request poses, but render
13through the normal Chrome compositor pipeline.
14It serves as a basic mode that requires only some way to get orientation poses.
15
16## Immersive:
17Immersive sessions are where the site wishes to request poses, then render
18content back to a display other than chrome. The common case for this is Head
19Mounted Displays (HMD), like Vive, Oculus, or Daydream.
20
21## Environment Integration
22This type of session allows for environment integration by providing functions
23that allow the site to query the environment, such as HitTest. A Environment
24Integration session may also supply data in addition to the pose, such as a
25camera frame.
26
27# Renderer <-> Browser interfaces (defined in vr_service.mojom)
28VRService - lives in the browser process, corresponds to a single frame.  Root
29object to obtain other XR objects.
30
31XRDevice - lives in the browser process, implemented as XRDeviceImpl. Allows a
32client to start a session (either immersive/exclusive/presenting or
33non-immersive).
34
35VRServiceClient - lives in the renderer process.  Is notified when VRDisplays
36are connected.
37
38VRDisplayClient - lives in the renderer process.  Is notified when display
39settings change.
40
41# Renderer <-> Device interfaces (defined in vr_service.mojom)
42These interfaces allow communication betwee an XRRuntime and the renderer
43process.  They may live in the browser process or may live in the isolated
44service.
45
46
47## Data related:
48All sessions need to be able to get data from a XR device.
49
50XRFrameDataProvider - lives in the XRDevice process.  Provides a way to obtain
51poses and other forms of data needed to render frames.
52
53## Presentation related:
54Presentation is exclusive access to a device, where the experience takes over
55the device's display, such as presenting a stereo view in an HMD.
56
57XRPresentationProvider - lives in the XRDevice process.  Implements the details
58for a presentation session, such as submitting frames to the underlying VR API.
59
60XRPresentationClient - lives in the renderer process.  Is notified when various
61rendering events occur, so it can reclaim/reuse textures.
62
63# Browser <-> Device interfaces (defined in isolated_xr_service.mojom)
64The XRDevice process may be the browser process or an isolated service for
65different devices implementations.  A device provider in the browser will choose
66to start the isolated device service when appropriate.
67
68XRRuntime - an abstraction over a XR API.  Lives in the XRDevice process.
69Exposes a way for the browser to register for events, and start sessions (Magic
70Window or Presentation).
71
72XRSessionController - Lives in the XRDevice process.  Allows the browser to
73pause or stop a session (MagicWindow or Presentation).
74
75XRRuntimeEventListener - Lives in the browser process.  Exposes runtime events
76to the browser.
77
78# Browser <-> XRInput interfaces (defined in isolated_xr_service.mojom)
79IsolatedXRGamepadProvider and IsolatedXRGamepadProviderFactory - Live in the
80XRInput process, and allow GamepadDataFetchers living in the browser process
81to expose data from gamepads that cannot be queried from the browser process.
82
83The XRInput process may be the browser process or a separate process depending
84on the platform.
85
86# Test interfaces (defined in browser_test_interfaces.mojom)
87XRTestHook allows a test to control the behavior of a fake implementation of
88OpenXR, and potentially other runtimes.  This allows testing the entire stack
89of Chromium WebXR code end-to-end.
90