Creating threads to update visualization asynchronously #2656
Conversation
execution is slower,thread not stopping gracefully
pending- eipstein not rendering prply(check other models) stopping thread(use_thread) graph inaccuracy
implementing bi-directional threads is ensuring synchronization between model execution and visualization, though this is resulting in reduced performance.
takes care of valueError and CancelledError. pending changes:clean code
optimal performance in browser and jupyter
In use_threads, the threads for step and vis may compete for GI leading to slower execution, especially when sharing resources. In contrast, use_task, which is asyncio-based, avoids GIL contention.
for more information, see https://pre-commit.ci
|
Performance benchmarks:
|
|
Thanks for the PR and the detailed PR message! I’m on vacation the whole of February, so I will leave the review to other maintainers. Have you also tried using a separate thread for every figure? |
|
Thanks! Hope you have a great vacation! |
…control This should improve the overall functionality and reliability of the SimulatorController, particularly in scenarios where stopping the execution is necessary.
That's an excellent point. You're right. Another option could be that a new thread is used to draw all figures for a single step. Then the figures for a certain step will be ready at the same time. You would have to guarantee that each frame is displayed for about the same time (or for a minimum duration). It's up to you how complicated you make it in this PR. We could also keep this PR to a minimal, simple implementation and implement further ideas in future PRs. |
|
Yes, this PR ensures a single thread handles drawing all figures together for a specific step, ensuring synchronization.
Noted, currently even if the play interval is set, the model doesn’t always visualize it correctly, and the user has to manually adjust it leading to poor responsiveness.I'll start working on this and create a new PR to handle this issue. |
Summary
This PR introduces a thread-based mechanism to handle model updates and visualization rendering concurrently. It ensures smooth execution of simulations by separating model step execution and visualization updates into independent threads, improving performance and responsiveness during simulations.
Fixes #2604
Motive
Previously, the visualization process could become a bottleneck during rapid simulations, as rendering was tightly coupled with model updates. This caused delays and UI responsiveness issues. By separating these operations into threads, the model execution is no longer hindered by the visualization process.
Implementation
Handles visualization updates triggered by threading.Event (visualization_pause_event) to synchronize rendering with model steps.
Implemented visualization_pause_event to signal the visualization thread after each model step is completed, ensuring rendering happens efficiently without blocking the simulation.
Usage Examples
Play Button Behavior: The play button now ensures the simulation continues smoothly.
Concurrent Rendering: Visualization and simulation run in parallel, reducing delays.
Before
After
Additional Notes