addAnchor() may need XRFrame

[takahirox]

In the explainer XRSession.addAnchor() takes two arguments, they are pose and reference space the pose is relative to.

I think .addAnchor() inside may need to convert the pose to another space for underlying AR system. In the newest WebXR API spec handling pose is bound to frame (XRFrame.getViewerPose/getPose()). So I speculate .addAnchor() may need XRFrame.

If that's true, there may be two options.

1. Adding the third argument frame(XRFrame) . XRSession.addAnchor(pose, referenceSpace, frame).
2. Move .addAnchor() to XRFrame. XRFrame.addAnchor(pose, referenceSpace).

Plus, with XRFrame these sentences in the explainer can be a bit simpler because we may omit the case where .addAnchor() is called out of animation callback.

In the case of anchors, the creation of the anchor should happen in the next frame and before the request animation frame of the session is called, if called during an animation frame callback. If called outside of an animation callback, the promise might resolve before the next request animation frame, but may not.

[bialpio]

Good point! The API should definitely explicitly express which frame is the one to be used for any potential pose calculations so it probably makes sense to move the method from XRSession to XRFrame (session will then be implied to mean the frame's session).

As for the phrasing related to creating anchors outside of animation callback, I don't think we can simply remove it. The WebXR application can also receive valid instances of XRFrames when handling select[/start/end] events (through XRInputSourceEvent) that can fire outside of request animation frame callback.

[takahirox]

Moving to XRFrame sounds good to me. Regarding the phrasing, oops I was missing those.