10-OCT-2025

0033

I think I’ve found the actual issue with the svg rendered, it’s blocking. It needs to run in it’s own thread and the UI talk to it, separate from tokio, started independently and globally available. tokio can run the UI and provide requests to the renderer, updating as new frames are available. This may be what spawn_blocking does, I haven’t read the docs enough to grok it yet. I grepped for it and it’s not in current use anyway, so worth looking through, an old stackoverflow here also points toward it. My initial thought, however, was to either spawn a separate thread with an async channel, then start tokio, obviating the #[tokio::main] handle and thus DIYing it with this additional thread. The renderer side would also have to directly manage the Future I think, that seems messy.

I could also just try to implement Future for the svg rendering step itself, so that it’s callable in the async context directly. I think the implementation would just be a spawn_blocking call.

I may need to grant some access to the tokio runtime to do this?

https://tokio.rs/tokio/topics/bridging#spawning-things-on-a-runtime

Seems relevant.