Repository navigation
Dynamic Foveation #1420
Description
Dynamic foveation is an optimization technique that adjusts rendering quality based on where the user is looking.
I want to start a discussion about feasibility of supporting dynamic foveation in WebXR. With more devices supporting eye tracking.
For WebXR, this would need to be implemented without exposing gaze data to web content.
Could we do a reduced capability rendering mode? where the last steps of the render path are handled by WebXR in a way that can't be read back
/facetoface
Activity
AdaRoseCannon commentedon Nov 22, 2025
For WebGL this could just be a boolean we develop under WebXR
For WebGPU we will need support for VRR and it would just happen there, then in WebXR we state how we would produce a resource to be compatible with this.
/agenda
wrangelvid commentedon Nov 28, 2025
Tangentially related to foveation. In remote rendering applications (for gaming or robotics) foveation compression of streamed videos are becoming increasingly interesting to reduce the required bandwidth in high fov/resolution regimes.
Some encoders support quantization modulation of individual macroblocks. While I understand the privacy concerns with exposing gaze data directly, perhaps it could be discussed to expose the viewpoint location on WebXR layers.
Though exposing gaze data may provide the same foundation to support both dynamic foveation and foveation compression in streaming.
gidich commentedon Mar 24, 2026
+1 — This is becoming an increasingly important gap for the WebXR community to address.
WebXR now risks falling behind native XR platforms in a key area that directly impacts real-world adoption: performance on demanding workloads.
On native platforms, dynamic foveation is no longer hypothetical:
Meta Quest Pro supports mature Eye-Tracked Foveated Rendering (ETFR) via Horizon OS / OpenXR, delivering substantial GPU savings compared to fixed foveation (Meta’s own testing has shown ETFR providing noticeably higher savings than FFR, especially at higher resolutions).
Apple Vision Pro introduced a Foveated Streaming framework in visionOS 26.4+, enabling privacy-preserving dynamic foveation specifically for NVIDIA CloudXR streaming scenarios at high resolutions and low latency.
By comparison, WebXR currently only exposes Fixed Foveated Rendering through the experimental XRWebGLLayer.fixedFoveation property (primarily available today in Meta’s Quest browser). While this is a useful starting point, it is not a long-term substitute for dynamic, runtime-managed foveation on hardware that already supports it.
From the medical XR and virtual standardized patient perspective, this gap is practical rather than academic. It appears in simulation, procedural training, and other fidelity-sensitive experiences where sustained frame stability, thermals, and battery life directly affect usability and training effectiveness.
A privacy-preserving dynamic foveation mechanism in WebXR (where the browser or runtime internally manages the foveal region without exposing raw gaze data to content) could materially improve:
The privacy-preserving direction already discussed in this issue feels like exactly the right approach. At this stage, addressing dynamic foveation feels less like a speculative optimization and more like closing an emerging platform capability gap.
I’d strongly encourage the working group to move this toward a concrete proposal or extension discussion. I’d be happy to share concrete medical XR / virtual standardized patient use cases and performance observations if that would help prioritize or shape the design.
Thank you for the continued excellent work on WebXR!
gidich commentedon Oct 15, 2026
Following up on my earlier comment — recent headset announcements further widen this gap.
Meta VR Glasses (announced at Connect 2026, expected Spring 2027): Meta’s developer documentation explicitly lists them as supporting Eye Tracked Foveated Rendering (ETFR), the same dynamic/gaze-contingent feature available on Quest Pro. The device has four eye-tracking cameras (two per eye). Availability depends on eye-tracking permission, and Meta notes that native apps should check support at runtime.
Valve Steam Frame (launched/available 2026): Includes eye tracking (internal cameras) used for both:
There are also recent code references to a higher-resolution OLED variant (“Plano”) that appears to explore hardware-level foveated scaling.
These are two additional shipping or soon-to-ship platforms (covering both the Meta/Horizon OS ecosystem and the SteamVR ecosystem) where native/standalone and streaming experiences can already take advantage of eye tracking + dynamic foveation for meaningful GPU, bandwidth, thermal, and battery savings — while WebXR content remains limited to fixed foveation via
fixedFoveation.Given that Meta has now announced multiple devices with ETFR support, Valve has shipped eye tracking + foveated streaming/rendering on Steam Frame, and Apple has demonstrated privacy-preserving approaches on Vision Pro, it feels increasingly important for WebXR to have a path forward that does not require exposing raw gaze data. Happy to help with use cases or testing if the group wants to revisit this.
@Yonet (any upates to provide)
alexusgregorygrynkewich5-dev commentedon Oct 16, 2026
Eye tracking