Re: [w3ctag/design-reviews] WebXR Dynamic Viewport Scaling (#588)

@torgo - this feature was initially requested by the <model-viewer> developers. @elalish had provided feedback and a use case description on the [blink-dev thread](https://groups.google.com/a/chromium.org/g/blink-dev/c/-khmtb4puL4/m/3rHv2DcQAQAJ) where we were discussing the feature. @elalish wrote:
> Yes, I've been pressing hard for this viewport scaling feature as <model-viewer> currently has significantly lagging performance in WebXR as compared to both its on-page rendering and as compared to the native Scene Viewer app. It has been fairly standard practice for some time to dynamically reduce resolution to maintain frame rate, as GPUs only spend time on pixel blocks that have things to render, which in AR is usually not most of them. Only when you have a huge object or get very close to something are you having to run your shaders on all the pixels. Decreased resolution (especially while moving) is much less noticeable than decreased frame rate, and dynamic scaling is the only reasonable way to solve this, since performance varies dramatically due to camera position. 
>
> We have already implemented and tested support for this API by enabling it with the Chrome Canary flag. It works great and exactly as expected. Gives about a 4x increase in frame rate in the worst cases.

@torgo wrote:
> Since the explainer link points to a subsection of the WebXR explainer can this be considered to be a "small delta" on an already existing spec, rather than a new thing? If so, are there key questions or issues you would like our feedback on? Thanks!

In short, if you feel comfortable that this is a small-enough delta and you trust that the immersive-web group handled this with appropriate due diligence, we'd be fine with just a high-level sanity check to make sure that there isn't anything in this change that seems surprising or concerning.

While I'd personally consider it to be a small delta, the Chrome feature reviewers had pointed out that even small changes should go through the process to ensure that there aren't any potential surprises or issues that could cause long-term headaches for the web platform. Even if it had consensus within the immersive-web group, it hadn't gotten feedback or review from outside that group yet.

Alex Russell @slightlyoff had requested a TAG review in the [blink-dev thread](https://groups.google.com/a/chromium.org/g/blink-dev/c/-khmtb4puL4/m/CINhf1VOAQAJ):
> So, there isn't a way in our process today to skip filing for TAG review for new features, small or not, and in particular not when we're being asked to ship something first. We've been discussing for some time what such an exception might look like and we're actually working through a potential test case with a separate feature right now. I'm hopeful that we'll have some sort of text available in the next month that brings some clarity.

For background, a roughly equivalent feature had been part of the predecessor WebVR API, but it was removed from the initial WebXR specification to simplify it for the first version of that (see https://github.com/immersive-web/webxr/issues/617), with the intent being to bring it back later. It's not all that complex, but it's important to get the details right to ensure consistent behavior across implementations. We had discussions about that in https://github.com/immersive-web/webxr/issues/1091.

As far as specific feedback is concerned, https://github.com/immersive-web/webxr/issues/1091#issuecomment-663778266 and the following comments were discussing some of the subtleties of the API, and I think we got them all resolved to the satisfaction of the immersive-web group. I don't know how deeply you want to dive into this topic, but if you want more detailed information, or if anything jumps out at you as an obviously bad idea, please let me know.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/588#issuecomment-794279971