v139 · device

WebXR Depth Sensing Performance Improvements

Exposes several new mechanisms to customize the behavior of the depth sensing feature within a WebXR session, with the goal of improving the performance of the generation or consumption of the depth buffer. The key mechanisms exposed are: the ability to request the raw or smooth depth buffer, the ability to request that the runtime sto

concepts

  1. Depth Sensing Tips

    Depth-sensing data is delivered with lower latency in v139. AR apps using depth occlusion or scene understanding get fresher samples each frame.

  2. Raw vs Smooth

    The three new controls: request raw depth (cheap), smoothed depth (denoised), or pause the runtime entirely. Live false-colour render so you can see the noise / power tradeoff.

  3. Use-Case Router

    Pick a real WebXR scenario — AR occlusion, virtual shadows, hit test, body tracking, scene mesh, haptics — and a device. The router returns the recommended depthUsage / depthDataFormat / depthType plus the bandwidth bill.

  4. Depth Data Visualizer

    Attempts to start a WebXR session with depthSensing optional. Visualizes the depth buffer as a near-to-far heatmap canvas. Format and usage selectors show which paths are available. A smoothing toggle averages 3 frames. When WebXR is absent, a simulated depth map (sphere + floor) demonstrates the visualization concept with the XRFrame.getDepthInformation() code pattern.

why it shipped

Web Developers use the depth sensing feature for a number of reasons; however, the existing shape of the API needs some tweaking to accommodate for changes in hardware (non-eye-aligned depth buffers), and to improve performance of developer experiences who often don't need depth sensing during the full scope of their experience.

references