Clarify which frame `requestAsyncHitTestResult()` should return results for

[Nell Waliczek]

The first real-world hit testing features were added in PR immersive-web/webxr#493, including an requestAsyncHitTestResult() function. The initial design has this function exposed off of an XRFrame with the intention that the hit-test results will be relative to the frame on which they were requested.
In the PR comments and the Jan '19 F2F, there were concerns raised that this wasn't possible to implement on some platforms and, furthermore, would be out of accordance with the developer intention.
There are a number of variations to the API shape which are possible, but before we propose anything concrete, we need to get a deeper understanding of the desired behavior and platform limitations.

[Nell Waliczek]

@thetuvix left the following comment on immersive-web/webxr#493 (immersive-web/webxr#493 (comment))

Is the behavior of "request now, receive results later, but results are based on data from previous frame" what apps will actually want? Do we have a concrete scenario for wanting that?

I see two coherent paths for the following scenario:

At time A, the user presses a button. After some amount of wireless latency, the UA receives the press and sets controller state, available to the app for an XRFrame with forward-predicted time B. At the frame for forward-predicted time C, the app gets results that match either...

* Time A, when the press actually occurred.  This would be useful for hit-testing what a controller was pointing at back when the press occurred, (available through `XRInputSourcesChangeEvent.getHitTestSource()`)  _or_

* Time C, for the forward-predicted time at which the app will target its current frame.  This would be useful for a view-relative reticle. (available through `XRFrame.getHitTestResults(hitTestSource)`)

Time B seems arbitrary relative to the user's actions, and so going out of our way to return data for Time B but not Time A seems of low value. This makes me question if there is a strong value now for the arbitrary hit-test. (XRFrame.requestAsyncHitTestResults)

[Nell Waliczek]

@thetuvix also left this comment immersive-web/webxr#493 (comment)

A relevant nuance is that what XR APIs generally allow time-indexing of is dynamic data, for things like heads and controllers that are actually moving. In contrast, for static and semi-static data, such as planes and meshes, APIs generally only expose the latest snapshot of their poses and geometry.

Unless a plane itself is being posed smoothly every frame in a forward-predicted manner, the following may be a reasonable balance that gets apps what they need while imposing a minimal constraint on UA architecture:

* Raycast **from** the pose of the `XRSpace` at the exact historical or future time requested in the `hitTest` call.

* Raycast **against** the world geometry that is current at the moment when the data is delivered.

[Nell Waliczek]

@klausw, IIRC you had some comments on this topic at the F2F as well?

[Nell Waliczek]

Hey folks, I'm considering removing the requestAsyncHitTestResult() section of the explainer until we've got resolution on this issue. Yell if you object.

[Nell Waliczek]

Moving to AR module while we figure out the correct final location for this issue

[Piotr Bialecki]

Closing for now - promise-based API is out of scope for now.