Improve visualization performance through multi-threading

[EwoutH]

Mesa currently runs model execution and visualization rendering on the same thread, creating performance bottlenecks when running computationally intensive models with multiple visualizations. This impacts responsiveness, especially in Jupyter notebooks. The UI can lag or freeze during model execution since visualization updates block the main thread.

We could improve performance by leveraging Solara's use_thread() functionality to run visualizations on separate threads from model execution. This would allow the model to continue executing while visualizations update asynchronously.

There could be (at least) three threads:

1. Main thread for model execution
2. Separate thread for Solara UI/event handling
3. Worker thread pool for rendering visualizations (plots, space drawings, etc.)

Some key questions to resolve:

• How to handle thread synchronization between model and vis? (and how much is need? One direction or bi?)
• Should threading be configurable or always enabled?
• Thread per component vs shared thread pool?

Next steps would be to prototype basic thread separation, benchmark improvements, and document the threading behavior.

See also:

• Solara threading docs & examples: https://solara.dev/documentation/api/hooks/use_thread
• Mesa visualization code: https://github.com/projectmesa/mesa/tree/main/mesa/visualization

CC @quaquel @Corvince

[HMNS19]

This looks interesting! Can I start working on it?

[EwoutH]

Sure!

[HMNS19]

Few models (like Wolf-Sheep) throw errors with unidirectional threading. I went ahead and added bidirectional sync for the simulator.

Should we make bidirectional sync mandatory for all models, or keep it configurable? Also, any ideas on a better way to handle this—maybe using asyncio.Queue instead of events?

[EwoutH]

Few models (like Wolf-Sheep) throw errors with unidirectional threading. I went ahead and added bidirectional sync for the simulator.

Could you figure out why some models throw these errors? Do they need bidirectional sync, and if so any reason why?

CC @quaquel

[HMNS19]

I think the issue is happening because force_update calls the plot during the model stepping. This causes the plot to try to update while the simulation is still modifying the model data, leading to mismatched array lengths. Since the arrays aren't updated in sync, it triggers the error.