-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Rework winit runner #9034
base: main
Are you sure you want to change the base?
Rework winit runner #9034
Conversation
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.
Set `ControlFlow::WaitUntil` to the next tick update or redraw, whichever is closer. Prepare for changes in rust-windowing/winit#2900.
Send events for control from resource `WinitHandler`, which contains `EventLoopProxy`.
The top schedule was redefined so that fine control would not be impossible. - Schedule `Main` was split into `StartupFlow` and `UpdateFlow`. - The names of the sub-schedules (`Startup`, `Update`, etc.) have not been changed, so in many cases no migration is necessary. - Add `Control` schedule. - Each time an event is received from windows and devices, this schedule is run. - This is useful for responding to events regardless of whether tick updates take place. - Add `FrameReady` schedule. - Each time a frame is ready to be updated, this schedule is run. - This is the best place to decide whether to redraw. - Rename `Render` schedule to `RenderFlow`. Schedules that run sub-schedules are now named uniformly as `***Flow`.
c77e100
to
d2416a4
Compare
d2416a4
to
557408e
Compare
I believe this will also fix #4669, right? |
Should this PR be given priority over #8745 ? I'm starting to hit complex migrations on my PR, impacting event loop. |
@B-head I think you can remove the uncertainty of what time PR to adapt to. 2 of them are closed in favor of the last one. |
Hi folks, I just wanted to share that I am interested in this feature as a way to manually control when to render: https://discord.com/channels/691052431525675048/1166887503454810132/1166887503454810132 Is there any interest or plan to continue with this PR, or it's doomed to be forgotten/closed? |
This pull request is stacked on #8976.
Resolves #1343, Resolves #5984, Resolves #9087, Fixes #5713, Fixes #8080, Fixes #9040, Closes #7611.
Objective
Code example here.
Solution
ControlFlow::WaitUntil
to the next tick update or redraw, whichever is closer.WinitHandler
, which containsEventLoopProxy
.Redefine top schedules
The top schedule was redefined so that fine control would not be impossible.
Main
was split intoStartupFlow
andUpdateFlow
.Startup
,Update
, etc.) have not been changed, so in many cases no migration is necessary.Control
schedule.FrameReady
schedule.Render
schedule toRenderFlow
.Schedules that run sub-schedules are now named uniformly as
***Flow
.To do
WinitHandler::run
.Time
. Candidates:FixedTime
andTime
while fixing several problems #8964FixedTime
andTime
(ver. B) (proof-of-concept) #8946Time
to support fast and slow running.Optimize VBlank wait locations that cause slow tick updates when VSync is enabled.(It didn't matter much)WinitSettings.unfocused_mode
is set toUpdateMode::Reactive
#7974.Known Issues
TextBundle
randomly fails to initialize the character textures.If you encounter any other issues, please let us know.
Changelog
To be written later.
Migration Guide
WinitHandler::run
toPostStartup
schedule.WinitSettings
has been redefined in the rework.