Configurable dynamic plot aggregation based on zoom-level#4865
Conversation
d17bb54 to
75ff4ff
Compare
|
I couldn't really spot the differences in the video. Btw, what does MinMax actually do? I would have assumed it output two values, a min and a max. |
|
As we present this option to users (both in the SDK and in the UI) I think it's important we clarify that this is about aggregating when we have multiple points per pixel in the plot |
It's exactly what it does, and that results in a line that goes straight up between those two points, since they both live in the same "pixel column". |
dd80167 to
5b4e1d4
Compare
205d5e3 to
6e2eb83
Compare
Size changes
|
|
This is pretty sweet! |
a01bd3c to
633b697
Compare
| /// ``` | ||
| #[inline] | ||
| pub(crate) fn plot_id(space_view_id: re_viewer_context::SpaceViewId) -> egui::Id { | ||
| egui::Id::new(format!("plot_{space_view_id}")) |
There was a problem hiding this comment.
faster, less hacky
| egui::Id::new(format!("plot_{space_view_id}")) | |
| egui::Id::new(("plot", space_view_id)) |
| scattered, | ||
| } = attrs; | ||
|
|
||
| // We cannot aggregate two points that doesn't live in the same aggregation window to start with. |
67a7767 to
3f868a4
Compare

Make it so users can configure an aggregation strategy in the rare case where they either have so much data or are so zoomed out that most of their plot results in an overdraw blurb.
Because this builds on top of the range cache, the data is neatly laid out in a memory slice already so this is very cheap to compute.
In my tests, the
MinMaxstrategy has worked so well that I've decided to make it the default in the end... That might be controversial 😶.Offvs.MinMax, using the new gaussian walk benchmark:Checklist
mainbuild: app.rerun.ionightlybuild: app.rerun.io