IDL Proposal: Single event for all anchor update events.

[judax]

The current IDL proposal includes a single event to indicate anchor update per anchor. Would it be better to have a global event in XRSession to handle all the anchor updates per frame at the same time?

[blairmacintyre]

Do anchors always update, every frame? If so, we don't need an event at all.

Can anchors update at different rates? If so, we need an event per anchor, don't we?

If every anchor does not update every frame, than we need some way of knowing when they change. I would prefer events over polling and looking at the value of the matrix.

Could there be one event, with an array of anchors that changed?

[judax]

Anchors do not always have to update. It could even happen that they never have to update. So this is not deterministic. Depends on the underlying system. I think an event is justified -as polling is not a nice API for this. It could definitively happen that some anchors update at different rates, thus not all anchor have to update at the same time. The issue is mainly to discuss if there should be one event in session that indicates all the anchors that have been updated at that frame update or an event per anchor. I think both options support well any scenario and each have advantages and disadvantages.

…

On Wed, Aug 22, 2018 at 1:54 PM Blair MacIntyre ***@***.***> wrote: Do anchors always update, every frame? If so, we don't need an event at all. Can anchors update at different rates? If so, we need an event per anchor, don't we? If every anchor does not update every frame, than we need some way of knowing when they change. I would prefer events over polling and looking at the value of the matrix. Could there be one event, with an array of anchors that changed? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFcSKkfW3TksQzfLBIQ5_k7DwC3Jm3CWks5uTcULgaJpZM4WIJda> .

[blairmacintyre]

Ok, that all makes sense. I have no strong opinions, I agree that there are advantages and disadvantages. I don't know enough about the implications of the tradeoffs in terms of web browser architectures (e.g., many events that cause the "exact number of correct updates", or one event where we do more work overall because it's likely we'll just read every anchor and possibly update every internal data structure that is based on anchors), plus it likely depends on the number of anchors and the platform specifics as well, as you point out.

[thetuvix]

A related question is whether we offer a bulk polling API to get the latest relations of a set of XRCoordinateSystems to some base coordinate system, or stick with apps querying about object coordinate systems one at a time. A bulk event would feed naturally into a bulk query - in contrast, if apps have to handle multiple events, they may not know when the events are "done" and it's time to do the bulk query. If apps just handle each anchor update event one at a time as they come in, it may not matter.

From a different angle, a bulk query API could also reduce the need for the event in the first place - if an app has 10 active XRCoordinateSystems for 10 elements of environmental geometry, it could just poll for their positions and update their scene graph transforms unconditionally - the scene graph API would hopefully notice itself if the scene object's parent transform actually changed or not.

[bialpio]

I decided not to use events to notify about anchor updates. It's not entirely clear to me what it means that an anchor got updated - for example, the anchor can remain unchanged (since its properties are not really changing), but that does not mean that the poses returned from XFrame.getPose(anchorSpace, refSpace) are not changing (refSpace could've also changed this frame). This is the most important reason behind not having anchor update events, for other reasons see my reply to PR#29. Since the current draft of the API does not expose any events, I'm closing this issue now - please reopen or file a new one if you disagree.