Applications can optionally render to a subset of the WebXR viewport, using a scale factor that can be changed every animation frame. This is intended to be more efficient than resizing the full framebuffer which requires reallocation, and the UA can supply a recommended scale factor based on internal heuristics.

Motivation

Applications should have a way to adjust the rendered resolution on the fly, for example to help reach target framerates when scene complexity changes. The current `framebufferScaleFactor` mechanism isn't intended to be used on a per-frame basis since it is likely to require reallocating render buffers. See https://github.com/immersive-web/webxr/blob/master/explainer.md#controlling-rendering-quality for background. The need for this feature was discussed in the Immersive-Web WG in https://github.com/immersive-web/webxr/issues/1091 and group discussions. The WG reached consensus on https://github.com/immersive-web/webxr/pull/1132 and the feature was added to the current WebXR Editor's Draft specification, i.e. https://immersive-web.github.io/webxr/#dom-xrview-requestviewportscale . Explainer: https://github.com/immersive-web/webxr/blob/master/explainer.md#dynamic-viewport-scaling

Demos

• https://vps3a.glitch.me/
• https://modelviewer.dev/examples/webxr.html

Documentation

• https://github.com/immersive-web/webxr/blob/master/explainer.md#dynamic-viewport-scaling

Specification

Editor's draft

Status in Chromium

Blink components: Blink>WebXR

In developer trial (Behind a flag) (tracking bug) in:

• Chrome for desktop release 88
• Chrome for Android release 88

Consensus & Standardization

• Firefox: No signal
• Edge: No signal
• Safari: No signal
• Web Developers: No signals

Owner

• klausw@chromium.org

Comments

This feature is an incremental change to the pre-existing WebXR Device API Editor's Draft.

Search tags

Last updated on 2021-02-19