-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Render App systems are blocking the Main app's primary thread #9964
Comments
This is the non send data issue. Prepare Windows has to run on main thread because of that. Will be fixed by #9122. |
I think i.e. a lot of the docs here https://docs.rs/winit/latest/winit/window/struct.Window.html say that these api's can only be called from main thread on ios. |
This has been addressed in rust-windowing/winit#2985 and rust-windowing/winit#3045. Though keep mind that functions that return values might block the calling thread until these values are returned. |
Can I have a go at this issue? :) |
@jmintb absolutely; let us know what you find out! |
# Objective - Allow prepare windows to run off of the main thread on platforms that allow it. - Fixes #9964 on most platforms. ## Solution - Conditionally compile prepare windows for different OS's - Seems like it's only the call to `create_surface` that needs to run on the main thread here. - I've only tested this on windows, but I do see prepare windows running on other threads. --- ## Changelog - Allow prepare windows to run off main thread on platforms that allow it.
# Objective - Allow prepare windows to run off of the main thread on all platforms. - Fixes #9964 on all platforms. ## Solution - Running `prepare_windows` on the main thread on apple platforms is only mandatory to create surface, which is only needed during window creation. Split that part into its own system that happens before `prepare_windows` - Tested on macOS and iOS --- ## Changelog - Allow prepare windows to run off main thread on all platforms.
# Objective - Allow prepare windows to run off of the main thread on platforms that allow it. - Fixes bevyengine#9964 on most platforms. ## Solution - Conditionally compile prepare windows for different OS's - Seems like it's only the call to `create_surface` that needs to run on the main thread here. - I've only tested this on windows, but I do see prepare windows running on other threads. --- ## Changelog - Allow prepare windows to run off main thread on platforms that allow it.
…gine#11672) # Objective - Allow prepare windows to run off of the main thread on all platforms. - Fixes bevyengine#9964 on all platforms. ## Solution - Running `prepare_windows` on the main thread on apple platforms is only mandatory to create surface, which is only needed during window creation. Split that part into its own system that happens before `prepare_windows` - Tested on macOS and iOS --- ## Changelog - Allow prepare windows to run off main thread on all platforms.
Bevy version
main (f8fd93f)
What you did
I ran
cargo run --profile stress-test --features trace_tracy --example many_cubes
and viewed the trace in Tracy.What went wrong
I was expecting that no blocking systems from the render app would block the main app from progressing.
In this screenshot,
prepare_windows
is blocking UpdateAssets from terminating. Delaying it from terminating and blocking PreUpdate and subsequent schedules.We currently do not schedule tasks from the ComputeTaskPool onto the render app thread, it may be a good idea to avoid doing so with all dedicated app schedule threads.
The text was updated successfully, but these errors were encountered: