Defer XRWebGLLayer viewport scaling

[toji]

I'd like to propose that we defer specification of the XRWebGLLayer function requestViewportScaling until after we have reached Candidate Recommendation status.

Reason: While requestViewportScaling serves a unique purpose in allowing realtime quality changes, this is not the primary rendering quality knob available to developers. That would be the framebufferScaleFactor, which is set at layer creation time and will generally have a much larger performance/quality impact. I've heard feedback that this will be a very difficult feature to use effectively without supplying developers with more detailed frame timing and profiling information. This has proven to be a tricky feature for implementations to get right as well, with it being a persistent source of bugs and cross-browser compatibility issues since way back in the days of WebVR. And finally there's an outstanding issue (#541) regarding the timing of when exactly this change would apply to the layer that could be set aside in favor of focusing on more important functionality.

Due to all of the above, it seems like we could comfortably defer this advanced feature till after CR.

Forward compatibility: Since this is a function it's easy for JavaScript developers to feature-test for it's existence once it's been re-introduced.

This is part of what will be an ongoing effort to identify ways to simplify the core API surface. The intent is to make the initial release of the API easier to spec, review, and implement, which is turn will help us keep on track for hitting CR later this year.

[cwilso]

@thetuvix could you comment on this proposal?

[thetuvix]

Apologies for the delay! I’ve followed up with folks internally at Microsoft and they agree that the value of per-frame viewport adjustments is limited without per-frame CPU/GPU stats to complete the app’s feedback loop. On HoloLens, we’ve primarily seen apps “fire and forget” a viewport scale once up front, which would now be better handled by framebufferScaleFactor.

We’re fine to remove requestViewportScaling from WebXR 1.0.

[toji]

Thanks Alex! That's great to have confirmed. If anyone else wants to speak up for/against this method being in WebXR core I'm still happy to hear it, but I've speculatively put up a PR for the removal in the meantime. (#631)