More fine-tuned ability to control when the viewer advances time

[jleibs]

When using Rerun for real-time visualization, messages necessarily arrive in log_time order, and this is what drives our "Follow" behavior in the viewer.

The problem with this is that we immediately advance the viewer when the base data arrives (for example an image which other processing is done on top of), but when significant processing is involved, the additional data (for example semantic labeling), might not arrive until later. In the worst case this data doesn't show up until a frame or 2 later, at which point you're already showing a different image.

Giving a user a way to guarantee greater synchronicity in the viewer would be very powerful. This would mean they could log an image at some point and the viewer would receive it, but wouldn't show that image until the additional context had finished logging.

Marking this as a tracking issue because I think there are likely to be a few related features that will work together to give us this functionality.

[robertbagge]

Thanks for adding it here @jleibs

A solution idea that would let us log from parallel processes without needing to do any observation in another process would be.

Something like this in the viewer (Forgive the naming)

rr.create_synchronisation_namespace(namespace="Some", wait_timeout=1)

then in A,B and C

# Advances expected count in viewer
rr.register_for_synchronisation(namespace"Some")

Then in the viewer there could be a counter and and advance when it is reached or when wait_timeout has occurred

[jleibs]

Riffing a bit on Robert's suggestion I think there might be a way to handle this with a concept of annotating a group of entity paths as being "View Synchronized."

This could maybe even be done directly from the blueprint, which would have the nice benefit of being able to handle it even if you didn't include the information at log time.

The rough semantics of being "View Synchronized" is that when doing queries within a space view related to those entities, the time used for the query would always be min() of the time-stamps of the synchronization group on the given timeline, even if the current time-selector is further in the future.

We might even want to be able to extend this same concept to components within an entity where the same challenges apply.

This has the benefit of being a stateless value that we can derive from timeline and the set of entities instead of needing to worry about counters.