-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Link to Main
schedule docs from other schedules
#10691
Link to Main
schedule docs from other schedules
#10691
Conversation
Hmm, I don't think this is a helpful place for this. IMO the better solution is good module or book-level docs on the basics of scheduling. |
I agree, this is not ideal. Maybe I could replaced it with something like "see the Main schedule for more details how schedules are run", which explains what's going on quite clearly? |
crates/bevy_app/src/main_schedule.rs
Outdated
@@ -74,6 +74,10 @@ pub struct RunFixedUpdateLoop; | |||
/// | |||
/// Frequency of execution is configured by inserting `Time<Fixed>` resource, 64 Hz by default. | |||
/// See [this example](https://github.com/bevyengine/bevy/blob/latest/examples/time/time.rs). | |||
/// | |||
/// Note that schedules are not run in parallel, in particular, | |||
/// systems in the `FixedUpdate` schedule are not run in parallel with systems |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"systems in the FixedUpdate
schedule are all run before systems in the Update
schedule"
next question people are going to ask is: "okay, what's the order of execution then?", and you can change just a single word in docs to immediately answer it
8a60dd6
to
0b7a4bd
Compare
Changed wording/links to main. |
Main
schedule docs from other schedules
I incorrectly assumed that moving a system from `Update` to `FixedUpdate` would simplify logic without hurting performance. But this is not the case: if there's single-threaded long computation in the `FixedUpdate`, the machine won't do anything else in parallel with it. Which might be not what users expect. So this PR adds a note. But maybe it is obvious, I don't know.
I incorrectly assumed that moving a system from
Update
toFixedUpdate
would simplify logic without hurting performance.But this is not the case: if there's single-threaded long computation in the
FixedUpdate
, the machine won't do anything else in parallel with it. Which might be not what users expect.So this PR adds a note. But maybe it is obvious, I don't know.