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

Don't update model in LoopMode::Wait when there were no events #782

Merged
merged 1 commit into from
Nov 10, 2021

Conversation

zgotsch
Copy link
Contributor

@zgotsch zgotsch commented Aug 5, 2021

Pending some clarity from the winit maintainers about whether wait interruptions without events are allowed, this is an idea for a fix for LoopMode::Wait if they are.

See rust-windowing/winit#1985 for more info.
Fixes #781

@mitchmindtree
Copy link
Member

Thanks @zgotsch, looks good to me!

@mitchmindtree mitchmindtree merged commit b0cd597 into nannou-org:master Nov 10, 2021
mitchmindtree added a commit to mitchmindtree/nannou that referenced this pull request Dec 14, 2021
After landing nannou-org#782 I noticed that the `App` proxy's `wakeup` method
hasn't been functional since the last event loop refactor (when wgpu was
introduced).

I also noticed that nannou-org#782 makes the extra updates provided in the `Wait`
loop mode redundant. Previously, we ensured at least ~3 updates would
occur following the most recently received event. This was aimed at
allowing GUI's to update for a couple of extra frames to resolve subtle
1-3 frame animations, but I'm unsure this is really the right approach.
At the very least, the number of updates should be configurable as a
part of the `LoopMode::Wait` variant, but that can wait for a future PR.
mitchmindtree added a commit that referenced this pull request Dec 17, 2021
After landing #782 I noticed that the `App` proxy's `wakeup` method
hasn't been functional since the last event loop refactor (when wgpu was
introduced).

I also noticed that #782 makes the extra updates provided in the `Wait`
loop mode redundant. Previously, we ensured at least ~3 updates would
occur following the most recently received event. This was aimed at
allowing GUI's to update for a couple of extra frames to resolve subtle
1-3 frame animations, but I'm unsure this is really the right approach.
At the very least, the number of updates should be configurable as a
part of the `LoopMode::Wait` variant, but that can wait for a future PR.
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.

LoopMode::Wait not working on macOS
2 participants