Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to enable temporal smoothing in follow mode #6105

Open
jleibs opened this issue Apr 24, 2024 · 1 comment
Open

Option to enable temporal smoothing in follow mode #6105

jleibs opened this issue Apr 24, 2024 · 1 comment
Labels
enhancement New feature or request 📺 re_viewer affects re_viewer itself

Comments

@jleibs
Copy link
Member

jleibs commented Apr 24, 2024

Users are currently forced to choose between two modes of playback:

  • In play mode the time cursor increments smoothly. This is nice for offline playback when we already have the data, but is hard to use in live mode since you need to precisely match the offset and rate of data.
  • In follow mode the time cursor continuously jumps to the new data at the end of the timeline, but this lacks some of the smoothness of follow mode.

This is particularly noticeable in a windowed plot when viewing the data as part of a realtime stream. Any burstiness in the data, such as from network jitter, or from larger payloads like images in the data-stream cause the plot to feel stuttery.

It would be nice to have the option to turn on some degree of smoothing in follow mode at the cost of a bit of additional latency. We should be able to dynamically track both a max-latency and rate of progression of the current timeline in order to progress time forward as smoothly as possible while accounting for burstiness.

In the case of large outliers, we could then jump to the end and reset the estimator.

@jleibs jleibs added enhancement New feature or request 📺 re_viewer affects re_viewer itself labels Apr 24, 2024
@emilk
Copy link
Member

emilk commented Apr 25, 2024

I don't think it need to add latency if the "smoothed" value is set to alway over-estimate the time, i.e. be sightly ahead of the incoming time points. In fact, we HAVE to do that to always see the latest incoming data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request 📺 re_viewer affects re_viewer itself
Projects
None yet
Development

No branches or pull requests

2 participants