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