xrCompatible false per default, canvas made compatible on demand #15027
Conversation
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15027/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/15027/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/15027/merge#BCU1XR#0 |
|
Visualization tests for WebGPU (Experimental) |
|
WebGL2 visualization test reporter: |
|
@RaananW : please document it here: https://doc.babylonjs.com/breaking-changes |
This is a breaking change that should never influence any of our users.
We set the canvas to be xrCompatible per default. mainly because there was no downside for the devs, and they could override this. However, this thread has shed some light on a single issue that was found with it - https://forum.babylonjs.com/t/browser-back-forward-cache-is-blocked-when-using-babylon-js-due-to-webxr/49903, namely browser back-forward cache is blocked when using a WebXR-enabled canvas.
This PR sets the flag to false per default and simplifies the mechanism in which a canvas is prepared for XR compatibility.
Please wait with merging this until the community has tested the snapshot, as I only have an emulator for the time being. Of course, it works correctly in both the windows XR emulator and the WebXR web-based emulator