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

Improve the gap-detector #1363

Merged
merged 1 commit into from Feb 21, 2023
Merged

Improve the gap-detector #1363

merged 1 commit into from Feb 21, 2023

Conversation

emilk
Copy link
Member

@emilk emilk commented Feb 21, 2023

Sparked by #1358

In the time panel we collapse large gaps in the data so that if you record a few minutes today and a few minutes tomorrow you won't need to scroll and zoom so much. But when is a gap big enough to warrant collapse?

The previous logic could sometimes produce way too many collapsed gaps, sapping performance and usability.

This PR changes the logic completely. The new logic only collapses a gap if it would shrink the whole timeline by at least some significant amount, which right now is hard-coded to 35% (more if there is very few datapoints). It also adds a new upper limit, so that we never collapse more than 20 gaps.

At the end of the day, this is just an improved heuristic, and still not "perfect", whatever that would mean.

Checklist

  • I have read and agree to Contributor Guide and the Code of Conduct
  • I've included a screenshot or gif (if applicable)
  • I've added a line to CHANGELOG.md (if this is a big enough change to warrant it)

@emilk emilk added 🪳 bug Something isn't working ui concerns graphical user interface 📺 re_viewer affects re_viewer itself 📉 performance Optimization, memory use, etc labels Feb 21, 2023
@teh-cmc teh-cmc self-requested a review February 21, 2023 08:44
Copy link
Member

@teh-cmc teh-cmc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely much much more conservative than the previous heuristics but after playing around with it for a bit... yeah I think it's nicer all around, definitely.

// This is partially an optimization, and partially something that "feels right".
let min_gap_size: u64 = match time_type {
TimeType::Sequence => 9,
TimeType::Time => 100_000_000, // nanos!
Copy link
Member

@teh-cmc teh-cmc Feb 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
TimeType::Time => 100_000_000, // nanos!
TimeType::Time => 100_000_000, // 100ms

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sort of prefer the reader having to do their own math rather than adding a comment that is going to be outdated the next time someone changes that line

@emilk emilk merged commit 9d5b0d6 into main Feb 21, 2023
@emilk emilk deleted the emilk/better-gap-maker branch February 21, 2023 11:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🪳 bug Something isn't working 📉 performance Optimization, memory use, etc 📺 re_viewer affects re_viewer itself ui concerns graphical user interface
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants