[Merged by Bors] - Increment FrameCount in CoreStage::Last. #7477
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
IceSentry
approved these changes
Feb 2, 2023
alice-i-cecile
added
C-Bug
alice-i-cecile
approved these changes
Feb 2, 2023
alice-i-cecile
added
S-Ready-For-Final-Review
irate-devil
approved these changes
Feb 2, 2023
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Feb 2, 2023
# Objective During testing, I observed that the `FrameCount` resource (`bevy_core`) was being incremented by `FrameCountPlugin` non-deterministically, during update, subject to the whims of the execution order. The effect was that the counter could and did change while a frame was still in flight, while user-systems were still executing. ## Solution I have delayed the incrementing of the `FrameCount` resource to `CoreStage::Last`. The resource was described in the documentation as "*a count of rendered frames*" and, after my change, it actually will match that description. ## Changes - `CoreStage::Last` was chosen so that the counter will be `0` during all earlier stages of the very first execution of the schedule. - Documentation added declaring *when* the counter is incremented. - Hint added, directing users towards `u32::wrapping_sub()` because integer overflow is reasonable to expect. ## Note Even though this change might have a short time-to-live in light of the upcoming *Stageless* changes, I think this is worthwhile – at least as an in-code reminder that this counter should behave predictably.
|
Pull request successfully merged into main. Build succeeded:
|
bors
bot
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
During testing, I observed that the
FrameCountresource (bevy_core) was being incremented byFrameCountPluginnon-deterministically, during update, subject to the whims of the execution order.The effect was that the counter could and did change while a frame was still in flight, while user-systems were still executing.
Solution
I have delayed the incrementing of the
FrameCountresource toCoreStage::Last. The resource was described in the documentation as "a count of rendered frames" and, after my change, it actually will match that description.Changes
CoreStage::Lastwas chosen so that the counter will be0during all earlier stages of the very first execution of the schedule.u32::wrapping_sub()because integer overflow is reasonable to expect.Note
Even though this change might have a short time-to-live in light of the upcoming Stageless changes, I think this is worthwhile – at least as an in-code reminder that this counter should behave predictably.