Applications can optionally render to a subset of the WebXR viewport, using a scale factor that can be changed every animation frame. This is intended to be more efficient than resizing the full framebuffer which requires reallocation, and the UA can supply a recommended scale factor based on internal heuristics.
This is a small addition to the WebXR API, there is consensus in the working group and agreement to go forward with it. The API is designed to be trivially easy to implement as a no-op. The UA can simply ignore the application-requested scale factor, and providing a suggested scale factor is also optional.
The API is available on all WebXR-supported platforms, but this is currently a no-op on Windows VR platforms. It's supported for Android for AR and VR.
Hey Klaus,Thanks for filing the intent. You list no TAG review, which is a bit of a red flag. Was this feature covered by a different review, perhaps?
I know that the XR interfaces have been a topic of continual TAG attention since I served, which is now several years ago. When was this method added to the draft spec? A quick look suggests that this feature was in previous drafts, dropped, and is now being revived under this signature? Is that correct?
Regarding developer enthusiasm, would be great to either hear from developers here (as we're the first being asked to ship) or from the results of a completed Origin Trial. As I don't see an OT for this, can you perhaps outline why that wasn't pursued here?
RGFIIUU6R8U6UUU
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.Thanks,-EmmettOn Mon, Nov 9, 2020 at 2:55 PM Tifow Subane <tifo...@gmail.com> wrote:
RGFIIUU6R8U6UUUOn Monday, November 9, 2020 at 2:03:01 PM UTC-8 Klaus Weidner wrote:[Updated Cc: for Chris and Emmett using their @google.com emails.]On Fri, Nov 6, 2020 at 11:46 AM Alex Russell <sligh...@chromium.org> wrote:Hey Klaus,Thanks for filing the intent. You list no TAG review, which is a bit of a red flag. Was this feature covered by a different review, perhaps?I was under the impression that this doesn't necessarily need a separate TAG review due to being a small modification of an existing API that has cross browser support. What's the recommended way to proceed here?
Web developers: No signals This feature was strongly requested by <model-viewer>, and initial feedback about the implementation was positive.Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
NoThe API is available on all WebXR-supported platforms, but this is currently a no-op on Windows VR platforms. It's supported for Android for AR and VR.
Is this feature fully tested by web-platform-tests?
YesTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1133381Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1135292Sample links
https://vps3a.glitch.me/
https://modelviewer.dev/examples/webxr.htmlLink to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5640976515203072This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKTKFrauU5u8s%3Dbr6g7NKO2QAyG-%3DZe2giYZCrvyho8e7sNjnA%40mail.gmail.com.
On Mon, Nov 9, 2020 at 3:28 PM 'Emmett Lalish' via blink-dev <blin...@chromium.org> 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.Thanks,-Emmett
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANr5HFXG%2B-9h3uySDS2puZsrHEx9%3D2jySbTtCL8tT0RQoaVOew%40mail.gmail.com.
We're now targeting M89 for the feature. I don't have specific information about developers other than <model-viewer> using the feature behind a flag at this time, I'll reach out again to see if I can get more feedback.
chri...@chromium.org wrote:Please file for official signals on these.Sorry, I had initially missed this in the response. I've filed requests for official signals:https://github.com/mozilla/standards-positions/issues/473I haven't heard back from the TAG review so far. Would it be OK to proceed with enabling the feature for the 89 branch (see https://chromium-review.googlesource.com/c/chromium/src/+/2518764), and if needed revert that if the launch approval isn't ready in time for 89 stable?
On Wed, Dec 16, 2020 at 4:34 PM Mounir Lamouri <mlam...@google.com> wrote:On Wed, 16 Dec 2020 at 15:40, Klaus Weidner <kla...@google.com> wrote:We're now targeting M89 for the feature. I don't have specific information about developers other than <model-viewer> using the feature behind a flag at this time, I'll reach out again to see if I can get more feedback.As mentioned before, because this API is meant to allow web developers to improve the performance of their application when using AR, we consider this something that everyone should be using. The Model Viewer project saw drastic improvements on low end devices where the default sized canvas setup by WebXR didn't allow the device to keep up at 30fps.-- Mounir
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFU2V80YYKU3XAHJR-TpK8NFb23_MDxjmztEqBtGOingHH9-yw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8xjy0SRSGqENYbG6h7hqfpeBky%2B0%3DJGrXurSiYu3S28w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcHUEUcbqjpvq9pc_joVGTRCrC1Pzde_5gHUiKNZZSxQA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc79ad11-3f85-418d-a114-216274e5de13n%40chromium.org.