### What When moving over to the new blueprint store, we temporarily lost the ability to persist blueprints. This is one of the major regressions currently preventing us from releasing main (See: #2529) This PR adds new methods to the `store_hub`: - `persist_app_blueprints` - `try_to_load_persisted_blueprint` The blueprints are stored using the standard rrd file format. They go into a sub-directory of our app-state storage: - Linux: /home/UserName/.local/share/rerun/blueprints/ - macOS: /Users/UserName/Library/Application Support/rerun/blueprints/ - Windows: C:\Users\UserName\AppData\Roaming\rerun\blueprints\ We only store a single blueprint in this folder per app-id. Any time we change the app_id via the `store_hub` (such as when loading an rrd) we will search the directory for a persisted blueprint and then load it. We track the `insert_id` on the active blueprint to determine if we need to save back out to disk again. I've tested to confirm that in most cases when we restore from blueprint we don't do anything weird like re-modify the blueprint and save it again. ### Additional Notes: The way that DataBlueprint/AutoValues work required a workaround that I don't particularly love, but does seems to be workable until we refactor to get rid of more of the serde business. - After implementing blueprint-loading, I noticed that every time we start the app fresh, we see a cycle where the AutoValue for `pinhole_image_plane_distance` goes from Auto(100.06751) -> Auto(1) -> Auto(100.03121). Even ignoring the transient jump due to view bounds being a frame delayed to populate, the Auto-value itself is unstable from run to run. This meant that every time we started the app, we would do a new insertion which would cause the blueprint to immediately get saved again. - The work-around is to replace the usage of `!=` (PartialEq) with a conceptually equivalent method `has_edits` for the DataBlueprintTree. We now consider all values of Auto to be considered a match. This seems to work out fine since we (should?) always recompute Auto values at the beginning of each frame. - Longer term, I think the right solution is to move the Auto values out of the blueprint and into the AppState so they persist frame-to-frame and don't even show up in the blueprint comparison logic. However, DataBlueprintTree is a complicated piece of work, and plumbing through that state is proving to be challenging. ### Future work This currently only implements file-backed storage, so doesn't work with web-view. - #2579 ### Testing: * Run colmap fiat: ``` python examples/python/structure_from_motion/main.py --dataset colmap_fiat ``` * Adjust views * Exit application * Check the md5sum of the blueprint: ``` $ md5sum /home/jleibs/.local/share/rerun/blueprints/structure_from_motion.blueprint 03fab330d9c23ac3da1163c854aa8518 /home/jleibs/.local/share/rerun/blueprints/structure_from_motion.blueprint ``` * Run colmap fiat a *second* time. * Confirm the layout persists: ![image](https://github.com/rerun-io/rerun/assets/3312232/036d6ae9-6d3e-4abf-a981-cc46a7b6fe71) * Close rerun and verify the blueprint hasn't been changed: ``` $ md5sum /home/jleibs/.local/share/rerun/blueprints/structure_from_motion.blueprint 03fab330d9c23ac3da1163c854aa8518 /home/jleibs/.local/share/rerun/blueprints/structure_from_motion.blueprint ``` ### Checklist * [x] I have read and agree to [Contributor Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md) * [x] I've included a screenshot or gif (if applicable) * [x] I have tested [demo.rerun.io](https://demo.rerun.io/pr/2578) (if applicable) - [PR Build Summary](https://build.rerun.io/pr/2578) - [Docs preview](https://rerun.io/preview/pr%3Ajleibs%2Fsave_blueprints/docs) - [Examples preview](https://rerun.io/preview/pr%3Ajleibs%2Fsave_blueprints/examples)

Get main into a releasable state #2529

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Get `main` into a releasable state #2529