How to port code from WebVR to WebXR:

 to port code from WebVR to WebXR:

1. Deprecated APIs: Replace all deprecated WebVR APIs with their WebXR equivalents. WebXR uses a different set of APIs that are more flexible and comprehensive than those in WebVR.

2. Session Handling: In WebXR, instead of directly requesting a VR display and starting a VR session, you would need to ask the user agent for an XR device, then start a session.

3. Reference Spaces: WebXR introduces the concept of reference spaces, which replace the eye-level and stage-level frames of reference in WebVR. You'll have to update your code to use these new reference spaces.

4. Input Sources: WebXR has a more flexible and comprehensive system for handling input from a variety of devices. If your WebVR code is designed to handle input from specific devices, you'll need to update it to use the new WebXR input source APIs.

5. Viewer and Frame Data: In WebVR, you use getFrameData() to get the data needed to render a frame. In WebXR, you use the XRFrame.getViewerPose() method.

6. Animation Loop: In WebVR, you use VRDisplay.requestAnimationFrame(). In WebXR, you use XRSession.requestAnimationFrame().

7. Rendering: In WebXR, you don't render to the canvas directly. Instead, you render to XRWebGLLayers that are part of an XRSession.

Sure, let's take a simple "Hello, World!" example of a rotating cube in WebVR and port it to WebXR. Note that the code snippets below are simplified for illustration purposes and might require additional setup and error handling for a full production application.

WebVR Version

javascript
let vrDisplay, frameData;

initWebGL();
initWebVR();

function initWebGL() {
    // WebGL setup goes here
}

function initWebVR() {
    navigator.getVRDisplays().then(function(displays) {
        if(displays.length > 0) {
            vrDisplay = displays[0];
            frameData = new VRFrameData();
            vrDisplay.requestAnimationFrame(loop);
        }
    });
}

function loop() {
    vrDisplay.getFrameData(frameData);
    render(frameData); // your rendering function
    vrDisplay.requestAnimationFrame(loop);
}

WebXR Version

javascript
let xrSession, xrReferenceSpace;

initWebGL();
initWebXR();

function initWebGL() {
    // WebGL setup goes here
}

async function initWebXR() {
    if (navigator.xr) {
        xrSession = await navigator.xr.requestSession("immersive-vr", { optionalFeatures: ['local-floor', 'bounded-floor'] });
        xrSession.updateRenderState({ baseLayer: new XRWebGLLayer(xrSession, gl) });
        xrReferenceSpace = await xrSession.requestReferenceSpace('local-floor');
        xrSession.requestAnimationFrame(loop);
    }
}

function loop(time, xrFrame) {
    let xrViewerPose = xrFrame.getViewerPose(xrReferenceSpace);
    if (xrViewerPose) {
        let glLayer = xrSession.renderState.baseLayer;
        gl.bindFramebuffer(gl.FRAMEBUFFER, glLayer.framebuffer);
        for (let xrView of xrViewerPose.views) {
            // Render from the point of view of xrView
            render(xrView); // your rendering function
        }
    }
    xrSession.requestAnimationFrame(loop);
}

This code creates a VR session, sets up the WebGL context for rendering in VR, requests a 'local-floor' reference space (which provides an origin at the user's floor level), and enters the render loop.

Remember, these are simplified examples. In a real application, you would need to handle errors, manage WebGL resources, and account for different types of VR devices and input methods. You would also need a way to start and stop the VR session based on user input.

You may also want to consider using a library such as Three.js, which can handle much of this complexity for you and provides a higher-level API for 3D rendering. As of my knowledge cutoff in September 2021, Three.js has good support for both WebVR and WebXR.

The transition from WebVR to WebXR primarily involved a change in the APIs used to interact with VR/AR hardware. Here are some of the most important changes:

1. navigator.getVRDisplays(): This was a WebVR method used to get a list of all connected VR displays. In WebXR, the equivalent function is navigator.xr.requestSession(), which requests a session for XR content. Unlike getVRDisplays(), requestSession() returns a promise for a single XRSession object instead of a list of displays.

2. VRDisplay: This interface represented a VR display in WebVR. It has been replaced by the XRSystem interface in WebXR. XRSystem provides methods to get information about the XR device, check if a certain session mode is supported, and request an XRSession.

3. VRDisplay.requestAnimationFrame(): This method requested an animation frame for the VR display in WebVR. In WebXR, the equivalent method is XRSession.requestAnimationFrame(). It behaves in a similar way, but is called on an XRSession object instead of a VRDisplay.

4. VRDisplay.requestPresent(): This WebVR method was used to start presenting to the VR display. It has been replaced by the XRSession.updateRenderState() method in WebXR. Instead of directly presenting to the display, you now update the render state of the XR session.

5. VRFrameData: This interface represented all the data needed to render a single frame in WebVR. In WebXR, the equivalent is the XRFrame interface. You use the getViewerPose() and getPose() methods of XRFrame to get the data you need for rendering.

6. VREyeParameters: In WebVR, this interface was used to get information about the eyes of the VR display. In WebXR, the concept of eyes has been replaced with XRViews. You get a list of XRViews from an XRViewerPose object, which you can get from an XRFrame.

7. VRDisplayCapabilities: This interface represented the capabilities of a VR display in WebVR. In WebXR, capabilities are represented by the XRSessionMode and XRSessionInit dictionaries. You check if a certain session mode is supported by using the XRSystem.isSessionSupported() method.

8. VRStageParameters: This interface represented the stage parameters in WebVR. In WebXR, stages are represented by bounded reference spaces. You request a bounded reference space by calling XRSession.requestReferenceSpace() with the 'bounded-floor' option.

These changes reflect a shift in how the APIs conceptualize VR/AR hardware and sessions. The goal of these changes was to make the APIs more flexible, able to handle a wider range of hardware, and better aligned with how modern VR/AR hardware works.