Skip to content
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

Add InputState::stable_dt #1625

Merged
merged 1 commit into from May 12, 2022
Merged

Add InputState::stable_dt #1625

merged 1 commit into from May 12, 2022

Conversation

emilk
Copy link
Owner

@emilk emilk commented May 12, 2022

This provides a better estimate of a typical frametime in reactive mode.

Summary: when animating things, stop using unstable_dt and start using stable_dt.min(0.1).

From the docstring of stable_dt:


Time since last frame (in seconds), but gracefully handles the first frame after sleeping in reactive mode.

In reactive mode (available in e.g. eframe), egui only updates when there is new input
or something is animating.
This can lead to large gaps of time (sleep), leading to large [Self::unstable_dt].

If egui requested a repaint the previous frame, then egui will use
stable_dt = unstable_dt;, but if egui did not not request a repaint last frame,
then egui will assume unstable_dt is too large, and will use
stable_dt = predicted_dt;.

This means that for the first frame after a sleep,
stable_dt will be a prediction of the delta-time until the next frame,
and in all other situations this will be an accurate measurement of time passed
since the previous frame.

Note that a frame can still stall for various reasons, so stable_dt can
still be unusually large in some situations.

When animating something, it is recommended that you use something like
stable_dt.min(0.1) - this will give you smooth animations when the framerate is good
(even in reactive mode), but will avoid large jumps when framerate is bad,
and will effectively slow down the animation when FPS drops below 10.

This provides a better estimate of a typical frametime in reactive mode.

From the docstring of `stable_dt`:

Time since last frame (in seconds), but gracefully handles the first frame after sleeping in reactive mode.

In reactive mode (available in e.g. `eframe`), `egui` only updates when there is new input or something animating.
This can lead to large gaps of time (sleep), leading to large [`Self::unstable_dt`].

If `egui` requested a repaint the previous frame, then `egui` will use
`stable_dt = unstable_dt;`, but if `egui` did not not request a repaint last frame,
then `egui` will assume `unstable_dt` is too large, and will use
`stable_dt = predicted_dt;`.

This means that for the first frame after a sleep,
`stable_dt` will be a prediction of the delta-time until the next frame,
and in all other situations this will be an accurate measurement of time passed
since the previous frame.

Note that a frame can still stall for various reasons, so `stable_dt` can
still be unusually large in some situations.

When animating something, it is recommended that you use something like
`stable_dt.min(0.1)` - this will give you smooth animations when the framerate is good
(even in reactive mode), but will avoid large jumps when framerate is bad,
and will effectively slow down the animation when FPS drops below 10.
@emilk emilk merged commit 2e4138d into master May 12, 2022
@emilk emilk deleted the stable_dt branch May 12, 2022 09:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant