Skip to content

blueprint make_active doesn't work with the web viewer #8741

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

Closed
Wumpf opened this issue Jan 20, 2025 · 1 comment · Fixed by #8977
Closed

blueprint make_active doesn't work with the web viewer #8741

Wumpf opened this issue Jan 20, 2025 · 1 comment · Fixed by #8977
Labels
🟦 blueprint The data that defines our UI 🪳 bug Something isn't working 🕸️ web regarding running the viewer in a browser

Comments

@Wumpf
Copy link
Member

Wumpf commented Jan 20, 2025

Blueprints sent via send_blueprint arrive just fine but they're not made active, even when

Short repro:

import rerun as rr
import rerun.blueprint as rrb
import numpy as np


blueprint = rrb.Blueprint(rrb.Spatial2DView(origin=f"image", name="test name"))
rr.init("image_viewer")
rr.serve_web(
    open_browser=True,
    web_port=9072,
    ws_port=9073,
)
rr.send_blueprint(blueprint)

image = np.random.randint(0, 256, (96, 96, 3))
rr.log("image", rr.Image(image))

input("Press Enter to exit...")

The viewer evidently received the blueprint and made it the default (send_column by makes the blueprint the default and makes it active) but it doesn't switch to this blueprint unless prompted to do so from the ui.
This does not happen when spawning the native viewer (spawn=True on init).

Curiously, when using rr.init("image_viewer", default_blueprint=blueprint), the blueprint is set as default and visible!

See also https://discord.com/channels/1062300748202921994/1330599362774171768/1330599362774171768

@Wumpf Wumpf added 🕸️ web regarding running the viewer in a browser 🟦 blueprint The data that defines our UI 🪳 bug Something isn't working labels Jan 20, 2025
DerpDays added a commit to DerpDays/rerun that referenced this issue Feb 9, 2025
DerpDays added a commit to DerpDays/rerun that referenced this issue Feb 9, 2025
@DerpDays
Copy link
Contributor

DerpDays commented Feb 9, 2025

I ran into a similar issue when working in rust creating my own web socket server based off re_ws_comms

For this issue, the following code snippets are the issue:

let msg_is_data = matches!(data, LogMsg::ArrowMsg(_, _));
if msg_is_data {
inner.history.push(msg);
} else {
// Keep non-data commands around for clients late to the party.
inner.history.push_static(msg);
}

In this, the blueprint activation command is saved as static in the history whereas since actual blueprints are just of type ArrowMsg, they are saved as a normal log in the history. This means that further down:

for msg in &inner.history.messages_static {
if let Err(err) = client.send(tungstenite::Message::Binary(msg.clone())) {
re_log::warn!("Error sending static message to web socket client: {err}");
return;
}
}
for msg in &inner.history.messages {
if let Err(err) = client.send(tungstenite::Message::Binary(msg.clone())) {
re_log::warn!("Error sending message to web socket client: {err}");
return;
}
}

When a new client connects, static messages are sent first, and hence it tries to activate a blueprint that it doesn't yet have access to since the blueprint data is saved in the normal history.

A quick fix would be to log normal data before the static data, or to log actual blueprints as static with something like:

match data {
    LogMsg::ArrowMsg(store_id, _) if store_id.kind != StoreKind::Blueprint => {
        inner.history.push(msg);
    }
    _ => inner.history.push_static(msg),
};

Though in either case there are tradeoffs - should blueprints be static and exempt from gc (then someone swapping lots of blueprints may build up lots of static data), or if they are able to be gc'ed, then a blueprint may be cleaned up when it might be needed for a new client later.

In my opinion, out of the two options, blueprints should be static, which is what I've included in my PR, though there definitely is some way where we only keep the last blueprint set as default as static - though this would be added complexity.

oxkitsune pushed a commit that referenced this issue Feb 19, 2025
### Related
* Closes #8741

### What
Makes blueprint contents be saved internally as static (along with their
activation command), instead of as a normal message.

This fixes the issue with default blueprints not being activated on web
clients when a new user connects, since after this change blueprint data
is also saved as static, this means the blueprint data is now sent to
the client before the activation command (since the activation command
is read and sent to the sink after the blueprint data).

More info can be found in the related issue
[#8741](#8741 (comment)).

Edit: just seen that there is plans to move away from websockets to gRPC
so this will probably be irrelevant soon.

Signed-off-by: DerpDays <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🟦 blueprint The data that defines our UI 🪳 bug Something isn't working 🕸️ web regarding running the viewer in a browser
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants