Thanks Alex! I'm excited to see this shipped in Chrome. This feature is currently behind an experimental flag in the Meta Quest Browser because the underlying OpenXR API has a bug that will be fixed in the next version of our OS. Once that goes out, we will remove the experimental flag and I'll work on adding support in three.js.
On Fri, Nov 14, 2025 at 8:25 AM Chromestatus < [email protected]> wrote: > *Contact emails* > [email protected] > > *Specification* > > https://immersive-web.github.io/webxr/#xrvisibilitymaskchangeevent-interface > > *Summary* > Adds an XRVisibilityMaskChange event that will provide a list of vertices > and a list of indices to represent the mesh of the visible portion of the > user's viewport. This data can then be used to confidently limit the amount > of the viewport drawn to in order to improve performance. To better support > this event, XRView's are also given unique identifiers to allow easier > pairing with the associated masks. This is an extension to the core WebXR > specification. > > *Blink component* > Blink>WebXR > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebXR%22> > > *Web Feature ID* > webxr-device <https://webstatus.dev/features/webxr-device> > > *Motivation* > Without this change, pages are forced to draw to the full texture provided > for the corresponding viewport, when portions of this viewport will not > even be visible to the user, resulting in wasted work. By providing an > event to describe the clipped-to area of the viewport, developers can save > on per-frame work, and improve performance of their experiences, by > reducing the required fill rate by 5-10% depending on device. This is given > as an event because some system-level functionality may in fact capture the > entire viewport, and thus those systems would like to toggle between having > developers draw the entire viewport versus only the area visible to the > active user. > > *Initial public proposal* > *No information provided* > > *TAG review* > *No information provided* > > *TAG review status* > Not applicable > > *Risks* > > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/218) > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/155) Note that the > Apple Vision Pro does ship WebXR behind a flag. > > *Web developers*: Positive Note that Meta has a pending change to merge > into one of the popular WebXR libraries pending this shipping in other > browsers. > > *Other signals*: The feature was proposed by Meta, who I believe has this > implemented in the Quest browser. > > *Ergonomics* > This is an event that is fired with a typically smallish amount of data, > but also expected to only be triggered infrequently. The feature itself is > designed to help developers improve performance of their experiences by > reducing needless work. > > *Activation* > The structure of the event is designed to cleanly work with clipping logic > within glsl, and developers from Meta already have draft changes to merge > into THREE.js, a popular WebXR library to take advantage of this. > > *Security* > N/a > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > Feature is not exposed on WebView > > > *Debuggability* > *No information provided* > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > No > WebXR is not supported on WebView. Sessions are really only possible on > Windows and Android, but types are not blocked on other Desktop platforms. > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > https://wpt.fyi/results/webxr?label=experimental&label=master&aligned > Note that tests *do* run on the CQ. Results on wpt.fyi are blocked by > crbug.com/410607164 > > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > WebXRVisibilityMask > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/450538226 > > *Availability expectation* > Feature should be available on Meta Quest browser either now or soon. > > *Estimated milestones* > Shipping on desktop 144 > Shipping on Android 144 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > None expected > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5073760055066624?gate=6599862548299776 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69166702.050a0220.b6611.00a2.GAE%40google.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69166702.050a0220.b6611.00a2.GAE%40google.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGN7qDAqivD%2BX0g_HdexXTEbhMwvNc93rJMM696k%3DouHEKvNVA%40mail.gmail.com.
