With the modularization work happening in WebXR, the overhead of some optional dependencies and the overhead for the polyfill in general, it'd be great if a small script could include only the needed/requested modules.
This would save the overhead of shipping polyfills to browsers that do not need them, as well as provide a mechanism for optionally including (#56) other parts.
With the exception of Samsung Internet for GearVR, all browsers supporting WebVR/WebXR support modules; putting a collection of modules on a CDN with a lightweight entry may be a good solution for distributing the polyfill as a collection of files. Note that modules are inherently async, and the polyfill currently requires to be synchronously included, such that navigator.xr exists by the time user script runs. We could require await polyfill.ready() before interacting potentially; I know that this caused issues in the past with THREE.VRControls for example that created globals at loadtime (VRFrameData) which could twist developer expectations a bit.
Potential modules:
cardboard-vr-display (#56) - provide immersive VR on unsupported platforms
AR features
Mock Session - generates mock data for an XRSession for development/testing purposes
With the modularization work happening in WebXR, the overhead of some optional dependencies and the overhead for the polyfill in general, it'd be great if a small script could include only the needed/requested modules.
This would save the overhead of shipping polyfills to browsers that do not need them, as well as provide a mechanism for optionally including (#56) other parts.
With the exception of Samsung Internet for GearVR, all browsers supporting WebVR/WebXR support modules; putting a collection of modules on a CDN with a lightweight entry may be a good solution for distributing the polyfill as a collection of files. Note that modules are inherently async, and the polyfill currently requires to be synchronously included, such that
navigator.xrexists by the time user script runs. We could requireawait polyfill.ready()before interacting potentially; I know that this caused issues in the past withTHREE.VRControlsfor example that created globals at loadtime (VRFrameData) which could twist developer expectations a bit.Potential modules: