-
-
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
Main
/Render
schedules be run at different real timing.
#8976
base: main
Are you sure you want to change the base?
Conversation
Example |
5aab12f
to
c50c30d
Compare
@@ -896,19 +896,19 @@ mod test { | |||
// asset is loading | |||
assert_eq!(LoadState::Loading, get_load_state(&handle, &app.world)); | |||
|
|||
app.update(); | |||
app.world.run_schedule(Main); |
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.
I think this is worse: we're leaking internal details and making a very common operation more verbose.
Can we keep App::update
around and just call this on the main schedule label?
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.
I did not do any test code refactoring, so it is verbose. 😅
Generally, &mut World
is passed in the exclusive system, so it is basically never used in that form. Probably in the form of runner functions and test code only.
And this PR will no longer be used in the engine code. So I think the maintenance will be forgotten and App::update
will stop working somewhere.
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.
Following up on @alice-i-cecile 's question, can we keep App::update()
?
It is used in tests and examples, and replacing it with the four-line stanza makes it more difficult to write tests that need to run schedules. Making testing more difficult should be avoided. I say this after adding easily a dozen app.update()
calls in the stepping PR for an example demonstrating stepping.
I think the maintenance will be forgotten and App::update will stop working somewhere.
The same argument applies if we replace the dozens of the existing App::update()
calls with four other lines. The difference is that we'll only need to fix App::update()
when it breaks.
I think we do need for some function to exist on mut App
that is the equivalent of "run everything".
c50c30d
to
d0cd48e
Compare
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.
What's the goal of this PR? Is it to make it possible to call the the main schedule and the render schedule separately in the runner?
} | ||
|
||
// skip setting up when using PipelinedRenderingPlugin | ||
if app.world.get_resource::<MainThreadExecutor>().is_some() { |
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.
MainThreadExecutor
may not exist after we remove non send resources from the world. Is there another way of detecting that PipelinedRenderingPlugin
is in use?
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.
It seems that PipelinedRenderingPlugin
can be detected using App::is_plugin_added
.
But either way, if MainThreadExecutor
is removed, plugin will either panic or fail silently. Might it be better to change code further and make plugin always panic?
Want to include `SubApp` in a system function, but `ExclusiveFunctionSystem` requires `Sync`.
Moved the responsibility for running top-level schedules from `App` struct to the runner function.
d0cd48e
to
91bb64d
Compare
I made a mistake and did not stack correctly on #8961, so I restored it. |
In terms of implementation, yes. In terms of designs, I want to remove obstacles to good design. Current status:
|
This pull request is stacked on #8961.
Objective
Allow the tick rate and frame rate to be configured to different values.
This PR supports the prerequisite that the
Main
schedule and theRender
schedule be run at different real timings.Note that tick rate and frame rate control will be implemented in a later PR.
Solution
Call
SubApp::extract
andSubApp::run
in the exclusive system. Add that system to theRender
schedule.Moved the responsibility for running top-level schedules from
App
struct to the runner function. Within the runner function, callWorld::run_schedule
to run schedules separately.Changelog
Added
app::SubApp::main_schedule_label
.app::ScheduleRunnerPlugin::main_schedule_label
.winit::WinitSettings::main_schedule_label
.winit::WinitSettings::render_schedule_label
.app::App::update_sub_apps
.Changed
render::Render
toapp::Render
.render::Render::base_schedule
torender::RenderSet::base_schedule
. (Back in place?)Sync
bounds toapp::App::runner
.Sync
bounds toapp::SubApp::extract
.RenderApp
instance will not be accessible aftercleanup
.Removed
render::pipelined_rendering::RenderExtractApp
.app::App::update
.app::App::main_schedule_label
.Migration Guide
The top-level schedules configuration has been moved from
App
to plugins for setting the runner function. SeeScheduleRunnerPlugin
orWinitSettings
.Replace the code that calls
App::update
in the runner function with the following:(The real timing for running top-level schedules has not yet been changed.)