Contact emails [email protected], [email protected], [email protected], [email protected]
Explainer https://github.com/immersive-web/layers/blob/master/explainer.md Specification https://www.w3.org/TR/webxrlayers-1 Summary WebXR Layers offers a more efficient way of drawing immersive content. In addition to support for native color and depth textures and texture arrays, it also provides support for different layer types that are managed by the system compositor (as opposed to javascript). Blink component Blink>WebXR Web Feature ID webxr-layers Motivation Performance: Layers are presented at the frame rate of the compositor but can be updated at a lower rate in the browser. The compositor can reproject layers at high refresh while the browser just needs to draw pixels when they need to change (instead of when the user moves) Legibility / visual fidelity: In a typical WebXR session, the pixels are resampled twice. This greatly affects text legibility by drawing into a layers, resampling only happens once. Power consumption / battery life: Because the browser only has to render the pixels that changed and can rely on the compositor to draw cubemaps and equirects, far less javascript and gl commands need to run in the browser which increases the system's battery life. Latency: Since the compositor always has the latest pose data and runs at very high system priority, the scene will “stick” to the right location which improves the experience and lowers user fatigue. A good example where this all comes to gether is 360 videos. With regular WebXR, a large framework and very careful coding is needed to do the reprojection. Typically, the resolution and framerates of the video is lowered so the experience can fit in the cpu/memory budget of the device. The efficiency gains of layers should enable such video to reach parity quality with what is possible in native apps on XR devices. Additionally it significantly reduces the amount of Initial public proposal https://github.com/immersive-web/proposals/issues/46 TAG review https://github.com/w3ctag/design-reviews/issues/528 TAG review status Issues addressed Risks Interoperability and Compatibility The spec is based upon the feature set of OpenXR with wide consensus/support across devices & operating systems. As long as the platform supports this standard (or something close to it), it should be possible to implement. Gecko: Defer (https://github.com/mozilla/standards-positions/issues/412) WebKit: Support (https://github.com/WebKit/standards-positions/issues/601) Safari WG member has no objections to the spec moving from the CG to the WG Web developers: Positive Positive initial response (privately) from multiple popular XR video framework developers. Other signals: Ergonomics The WebXR layers API is extending the WebXR feature set. Its primary use case is improved performance and rendering quality. Today, authors have to rely on large frameworks to render high quality 360 or 180 video and they have to be very careful to not overload the system. With layers, this is now natively supported by the browser and since the compositor will do a lot of the heavy lifting, the load on the browser is significantly lower. We expect this API to improve developer ergonomics in WebXR. Activation Not all user agents will have immediate support for this feature. To mitigate this, we are planning on creating a polyfill. Security This spec leans heavily on WebXR existing security mitigations. The spec calls out some additional rules. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No information provided Debuggability WebXR Layers are debugged in the same fashion as regular WebXR. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No The feature performs best if the platform has native support for layers which can be done through OpenXR or some other native API. We expect that most implementations will take that path. It might be possible to build a compositor into Chrome itself as a fallback. Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/webxr/layers?label=experimental&label=master&aligned Flag name on about://flags WebXR Projection Layers Finch feature name WebXRLayers Rollout plan Will ship enabled for all users Requires code in //chrome? False Tracking bug https://buganizer.corp.google.com/issues/409255534 Estimated milestones Shipping on Android 147 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). No information provided Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6634466544058368?gate=5852705186775040 This 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69838d31.050a0220.baa59.050a.GAE%40google.com.
