Skip to content

Commit

Permalink
Design proposal for blueprint store (#1582)
Browse files Browse the repository at this point in the history
  • Loading branch information
emilk authored Mar 24, 2023
1 parent 52ded92 commit 1a56cc2
Show file tree
Hide file tree
Showing 2 changed files with 89 additions and 39 deletions.
89 changes: 89 additions & 0 deletions design/blueprint_store.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
# Blueprint store
Status: pre-proposal

## Intro
How do we store our UI state? We want:

- To be able to set up the UI from logging SDK
- Save the UI state to disk
- Undo/redo

UI state include:

- Is the selection panel open? how wide?
- How are my space views organized?
- What data is shown in each space view

## Proposal

We have a separate “blueprint store”, implemented with the same DataStore code. We will therefore have both “data entities” and “blueprint entities”.

Each *view* has a unique `BlueprintId`. We have a few built-in `BlueprintId`s:

- `viewport`, `selection`, `stream`, …
- Then auto-generated uuids for each other space view, data group, layout, data blueprint, etc

The blueprint store is organized flatly by just blueprint id, e.g. `viewport.children = […]` where `children` is a *ui component (or “blueprint component”?). In this case `children` contain other blueprint ids (the views in the viewport).

The blueprint store has exactly one timeline: `ui_time` which is the local time of the application. This can then be used for undo and redo.

## Viewer
The viewer state would be completely driven by the blueprint store and the data store. Each frame we would basically query the blueprint store about the current state of the ui, which would then dictate the queries done to the data store.

The user save the data store and blueprint store to separate files.

### Python SDK
Something like this is very low-level, and not very ergonomic:

```py
rr.ui_log("top_bar", [("visible", false)])
space_view_bpid = rr.ui_new_space_view("My 3D view")
data_bpid = rr.new_data_blueprint("world/points")
rr.ui_log(space_view_bpid, [("category", "3d"), ("children", [data_bpid])])
rr.ui_log("viewport", [("children", [space_view_bpid])])
```

Adding high-level helpers on top of this is very desirable, but a lot of work.


### UI components
The ui components are quite specific for the type of blueprint. Here are a few example:

* `root`:
* `TimeControl` (globally selected timeline, time, play state, etc)
* Top bar:
* `visible`
* Blueprint panel:
* `visible`
* `width`
* Selection panel:
* `visible`
* `width`
* Time panel:
* `visibility` ("hidden", "collapsed", "expanded")
* Viewport:
* `children` (max one!)
* Layout
* `children`
* `type`: "horizontal", "vertical", "auto", …
* `sizes`: individual sizes of the children
* Space view
* `children` (data blueprints)
* `category` ("3d", "text", …)
* Data group
* `children`
* Data
* `entity_path` data entity path

To help make the transition easy we should consider creating a shim between `arrow2` and `serde`.


## Future work
We support data overrides and defaults using:

* `blueprint_id/default/$data_entity_path.component`
* `blueprint_id/override/$data_entity_path.component`

Can `$data_entity_path` be a pattern, or just a full path?

Example, default point size for everything in the viewport: `viewport/default/**.radius = 2.0pt`
39 changes: 0 additions & 39 deletions design/data_model_3.md

This file was deleted.

1 comment on commit 1a56cc2

@github-actions
Copy link

Choose a reason for hiding this comment

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

Rust Benchmark

Benchmark suite Current: 1a56cc2 Previous: 6e4ddaf Ratio
datastore/insert/batch/rects/insert 571338 ns/iter (± 2693) 554386 ns/iter (± 2668) 1.03
datastore/latest_at/batch/rects/query 1906 ns/iter (± 7) 1879 ns/iter (± 8) 1.01
datastore/latest_at/missing_components/primary 288 ns/iter (± 10) 288 ns/iter (± 0) 1
datastore/latest_at/missing_components/secondaries 441 ns/iter (± 0) 440 ns/iter (± 1) 1.00
datastore/range/batch/rects/query 151242 ns/iter (± 439) 151829 ns/iter (± 535) 1.00
mono_points_arrow/generate_message_bundles 52115175 ns/iter (± 1593272) 50479457 ns/iter (± 790654) 1.03
mono_points_arrow/generate_messages 137318708 ns/iter (± 1369729) 134935769 ns/iter (± 1182651) 1.02
mono_points_arrow/encode_log_msg 170578537 ns/iter (± 1505256) 167153280 ns/iter (± 598278) 1.02
mono_points_arrow/encode_total 359989554 ns/iter (± 2399368) 354994844 ns/iter (± 1336970) 1.01
mono_points_arrow/decode_log_msg 187711171 ns/iter (± 1111261) 187046236 ns/iter (± 1045895) 1.00
mono_points_arrow/decode_message_bundles 76577898 ns/iter (± 927598) 71967598 ns/iter (± 880957) 1.06
mono_points_arrow/decode_total 259892094 ns/iter (± 1734498) 254088789 ns/iter (± 1633199) 1.02
batch_points_arrow/generate_message_bundles 342372 ns/iter (± 745) 341021 ns/iter (± 1530) 1.00
batch_points_arrow/generate_messages 6277 ns/iter (± 18) 6274 ns/iter (± 37) 1.00
batch_points_arrow/encode_log_msg 370819 ns/iter (± 1737) 374497 ns/iter (± 8603) 0.99
batch_points_arrow/encode_total 733490 ns/iter (± 3067) 733510 ns/iter (± 3314) 1.00
batch_points_arrow/decode_log_msg 351943 ns/iter (± 1972) 344901 ns/iter (± 1061) 1.02
batch_points_arrow/decode_message_bundles 2009 ns/iter (± 7) 2043 ns/iter (± 9) 0.98
batch_points_arrow/decode_total 358459 ns/iter (± 1259) 353392 ns/iter (± 1167) 1.01
arrow_mono_points/insert 7093925796 ns/iter (± 27956825) 6880523644 ns/iter (± 13711923) 1.03
arrow_mono_points/query 1807768 ns/iter (± 14211) 1830781 ns/iter (± 16862) 0.99
arrow_batch_points/insert 2632710 ns/iter (± 27478) 2673906 ns/iter (± 11319) 0.98
arrow_batch_points/query 16225 ns/iter (± 83) 16155 ns/iter (± 109) 1.00
arrow_batch_vecs/insert 41987 ns/iter (± 4368) 42684 ns/iter (± 197) 0.98
arrow_batch_vecs/query 389523 ns/iter (± 478) 389424 ns/iter (± 1669) 1.00
tuid/Tuid::random 34 ns/iter (± 0) 34 ns/iter (± 0) 1

This comment was automatically generated by workflow using github-action-benchmark.

Please sign in to comment.