New debug option to show an actual timeline for the Blueprint

[jleibs]

What

• Resolves: UI Improvements: Blueprint-specific timeline view #4283

Lots of goodies here:

• Add a new toggle which opens a second timeline showing a view of the blueprint store.
• Introduce a Blueprint Timeline and log all blueprint events as temporal on the blueprint timeline.
• Make it possible to query data using the blueprint timeline.
• And last but not least, use the blueprint time control to drive all our viewport queries when we're in the blueprint inspection mode.

In debug, Ctrl-Shift-I now opens this inspector, or it's available via rerun debug menu.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[emilk]

I like the functionality, but I wonder if we can improve the implementation.

I understand this is a debug-only feature (for now!) and doesn't have to be perfect, but debug-features has a tendency to become official features over time, and if we can come up with a better design now, it would be good.

I'm in particular not a huge fan of current_query_for_entity_path. It is only sometimes used (current_query() remains), and it uses not only the given entity path, but the global modifier show_blueprint_timeline. This means changing which store to view in the streams panel can also change how the currently selected entity is shown in the selection panel.

I don't have an immediate better suggestion though. Baking in the StoreKind or StoreId into each selected Item seems like the clean way to go, but it is a rather big refactor (and outside the scope of this PR).

[emilk]

I find this misleading. It sounds like it opens a new panel with the time-stream of the blueprint data, but what it actually does is switch what store the streams panel shows.

I think this would be more clear if the bool was changed to a stream_panel_store: StoreKind, and this to

Suggested change

	/// Show a timeline of the blueprint data.
	#[cfg(debug_assertions)]
	ShowBlueprintTimeline(bool),
	/// Select what store is shown in the streams panel: the recording or the blueprint.
	#[cfg(debug_assertions)]
	SetActiveStreamPanelStore(StoreKind),

[emilk]

This feels quite inelegant.

I guess the alternative would be for the current Item selection to know what store it is on, i.e. that we don't select only an EntityPath, but an StoreId + EntityPath pair. I guess that's more work though, but did you consider it?

[jleibs]

Yeah, the need for this bit made me sad. I considered 2 options and both were further reaching than I wanted to tackle here:

1. As you suggest: adding it to the Selection context and then plumbing the information down into every data_ui element.
2. Introduce a GloballyQualifiedEntityPath (or equivalent name) which tracks StoreId + Path, and migrating many of our usages of EntityPath (specifically Selections) to use GQEP instead.

(2) is actually be preference at the moment because GQEP's with blueprint store-ids would also be helpful with the implementation of generalized hierarchical component-overrides that combine both log-centric (e.g. log-recursive) and blueprint-sourced overrides.

[emilk]

Will a tensor entity ever be on the blueprint timeline? I thought that was only applicable to stuff like containers and space view entities?

[emilk]

I guess I'm a bit confused why some current_query() has become current_query_for_entity_path, but not all.

[jleibs]

Will a tensor entity ever be on the blueprint timeline?

Yes -- data overrides will be stored in the blueprint. So if you set an override, and then select the blueprint entity representing that override you'll hit this code path.

I guess I'm a bit confused why some current_query() has become current_query_for_entity_path, but not all.

I scoped my search & replace to the data_ui elements which is the only context in which it should theoretically matter .

[emilk]

In the PR description this is called "blueprint inspection mode" which makes it sound more like a global mode, while "Show a timeline of the blueprint data." sounds like a change in one of the panels.

I think one problem is that while show_blueprint_timeline mostly changes the streams panel, it also does other things, like change how current_query_for_entity_path works.

[jleibs]

I think "blueprint inspection mode" is probably the better name and goes along with the explanation that while in this mode, the blueprint can't be edited.

[jleibs]

@emilk based on feedback I ended up making a number of changes:

• Rather than switching what the panel views, I actually open the blueprint as a second panel.
• Plumbed a bunch of store/query contexts through data_ui elements so that those elements can be explicit about the store/query context of the data_ui rather than doing their own guessing/hard-coding internally.
• I consolidated the logic for guessing the relevant store and query from the entity_path into a single helper function now scoped to selection_panel. We can get rid of this once Entities or Selections carry a bit more context, but this seemed like a reasonable compromise.

[emilk]

NOTE: this is a personal style preference, so feel free to ignore.

When deciding parameters order, I usually go with "environmental first, specific last". ctx is basically always the same, so it is always first. ui is likewise part of the environment (its where we happen to add widgets). I would therefore have put store before verbosity.

This helps keep the argument order somewhat consistent across the code base (ctx, ui, store, entity_path, component_path, time, …). Of course, there is a lot of room for interpretation here.

Also, it'd be a pain in the ass to change this now, so feel free not to change anything - I just wanted to spread what I consider a good practice :)

[jleibs]

Yeah, you've mentioned that before and I had the thought in my head while writing this code. If I was adding both query and store, I would have been more inclined to add it right after ctx at the beginning. But I found it easier to keep query & store together as a pair for this.

Open to doing parameter order reshuffling in another refactor-only PR and moving them both to the front. I'm also inclined to introduce some kind of "DataQueryContext" that combines those things just to cut down on all the arguments, which might also eventually include things like caches and override stacks.