Merge pull request #1083 from Manishearth/additional-views

Manishearth · web-flow · commit 91062412d1c4 · 2020-06-18T12:41:36.000-07:00
Add feature for secondary views
diff --git a/index.bs b/index.bs
@@ -30,6 +30,8 @@ spec:permissions-1;
     type:dfn; text:powerful feature
 spec:webidl;
     type:dfn; text:new
+spec:webxr-ar-module-1;
+    type:dfn; text:first-person observer view
 </pre>
 
 <pre class="anchors">
@@ -1350,6 +1352,42 @@ To <dfn for="XRView">obtain the projection matrix</dfn> for a given {{XRView}} |
 </div>
 
 
+Primary and Secondary Views {#primary-and-secondary-views}
+----------
+
+A [=view=] is a <dfn>primary view</dfn> when rendering to it is necessary for an immersive experience.
+
+A [=view=] is a <dfn>secondary view</dfn> when it is possible for content to choose to not render to it and still produce a working immersive experience. When content chooses to not render to these views, the user-agent MAY be able to reconstruct them via reprojection.
+
+<div class="example">
+Examples of [=primary views=] include the main mono view for a handheld AR session, the main two stereo views for headworn AR/VR sessions, or all of the wall views for a CAVE session.
+
+Examples of [=secondary views=] include the [=first-person observer view=] used for video capture, or "quad views" where there are two views per eye with differing resolution and fields of view.
+
+</div>
+
+<div class=note>
+While content should be written to assume that there may be any number of views, we expect a significant amount of content to make incorrect assumptions about the {{XRViewerPose/views}} array and thus break when presented with more than two views.
+
+Because user-agents may have the ability to use mechanisms like reprojection to render to these [=secondary views=] in lieu of the content, it is desirable to be able to distinguish between content that plans on handling these [=secondary views=] itself and content that is either oblivious to the existence of such [=secondary views=] or does not wish to deal with them.
+</div>
+
+To provide for this, user-agents that expose [=secondary views=] MUST support an "<dfn for="secondary views">secondary-views</dfn>" [=feature descriptor=] as a hint. Content enabling this feature is expected to:
+
+ - Handle any nonzero number of [=views=] in the {{XRViewerPose/views}} array.
+ - Handle the existence of multiple [=views=] that have the same [=view/eye=].
+ - Handle the size of the {{XRViewerPose/views}} array changing from frame to frame. <span class=note>This can happen when video capture is enabled, for example</span>
+
+When "[=secondary views/secondary-views=]" is enabled, the user-agent MAY surface any [=secondary views=] the device supports to the {{XRSession}}, when necessary. The user-agent MUST NOT use reprojection to reconstruct [=secondary views=] in such a case, and instead rely on whatever the content decides to render.
+
+Note: We recommend content use {{XRSessionInit/optionalFeatures}} to enable "[=secondary views/secondary-views=]" to ensure maximum compatibility.
+
+If [=secondary views=] have lower underlying frame rates, the {{XRSession}} MAY choose to do one or more of the following:
+
+ - Lower the overall frame rate of the application while the [=secondary views=] are active.
+ - Surface [=secondary views=] in the {{XRViewerPose/views}} array only for some of the frames. Implementations doing this SHOULD NOT have frames where the [=primary views=] are not present.
+ - Silently discard rendered content for [=secondary views=] during some of the frames.
+
 XRViewport {#xrviewport-interface}
 ----------
 
