[How] should applications be informed of changes in plane data?

[johnpallett]

Discussing how applications can determine when plane data has changed between rAFs.

[johnpallett]

copied from #2 - Blair says:

Why is this pull instead of push? Forcing folks to poll and step through the data to see if anything has changed seems awkward. In our polyfill we used two things:
events. When an existing thing had it's values changed, a subscriber could be notified. This is the pattern used in the anchor proposal, for example.
difference lists. In addition to the "current" plane (mesh) set, we had a list of new mesh objects and a list of deleted mesh objects available, so apps could update their internal data structures as needed.

[johnpallett]

copied from #2 - bialpio says:

I do think that adding an updated property on objects in the returned list will be useful - this is why we’d like to incubate the API and check where it’s awkward to use. Once there’s such property, it will be trivial to add a list with just the updated objects.

Events could work as well as long as we could guarantee that the subscriber is notified in the context that could draw, otherwise apps would have to maintain a list of all objects themselves and keep updating it. Instead of requiring users of the API to do so, we might just do it for them.
I think difference lists are a good idea. Just exposing an updated property should allow us to polyfill it.

[johnpallett]

copied from #2 - Blair says:

As the amount of data grows, forcing pages to iterate and compare seems unwise. Again, consider ARKit and ARCore, but also Hololens and ML1, as I walk around my house, going from room to room and floor to floor, only the local parts of the data are changing. Other distant parts do not change. Having applications perform at a consistent rate as the amount of data available to them grows requires that we avoid forcing them to scan through all the data more than they have to.

It may very well be that having a "updated" property on the objects is sufficient, especially if the objects have unique IDs associated with them (or are otherwise identifiable). It really depends on how "big" the list gets. A few dozen, or even a few hundred, is probably fine; after all, drawing them will be more expensive than peeking at a single property on each of them. I mostly want a way to know which objects have changed.

I think difference lists are a good idea. Just exposing an updated property should allow us to polyfill it

Agreed, that's probably a good compromise.

[blairmacintyre]

I think any solution that avoids apps having to examine the data is ok. I don't have a sense, for example, of how fine-grained things will get. For example, if we end up having a small number of relatively large meshes, then update events might be good; if we have hundreds of small meshes, putting an updated property on the meshes, may be better.

One issue with the property is when does it get cleared? Or is the property actually a time stamp (lastChanged), so that it's easy to do more interesting things.

[bialpio]

I really like the idea of making the property a timestamp, we can set it to the same timestamps that are reported to rAF callback. This way the application could check whether the plane was updated in the current frame by doing something like:

let time = …; // time is a parameter passed in to rAF callback
let plane = …; // some plane detected in the current frame
let is_updated = plane.lastChangedTime == time;

[bialpio]

I've uploaded a planes-notifying-about-removal.md file presenting different approaches for notifying application about removal of the planes, please take a look.

[bialpio]

I have added the support for lastChangedTime to Chrome’s experimental implementation of plane detection API - Blair, can you take a look and let me know what you think? The instructions for enabling the API can be found here.

[bialpio]

Closing stale issue - I will rework the explainer to make sure it matches the rest of WebXR APIs.