bb4aa22cf9
Previous version used [`SetTimer`] with `GetMessageW` for waiting. The downside of UI timers like ones created by `SetTimer`, is that they may be late by up to 15-16 ms. To fix this behaviour, I added use of high resolution timers created by [`CreateWaitableTimerExW`] with the flag `CREATE_WAITABLE_TIMER_HIGH_RESOLUTION`. In my previous experience, waiting on such timers have precision of roundly 0.5 ms which is the best available on Windows at the moment. I use [`MsgWaitForMultipleObjectsEx`] to wait simultaneously for both timer and newly arriving events. Unfortunately, high resolution timers are available only since Windows 10 1803. However: 1. Win 10 is already getting to the end of support, like all previous versions, so it is OK to rely on APIs introduced in it; 2. I use `dwMilliseconds` parameter of `MsgWaitForMultipleObjectsEx` as a fallback. It should perform not worse compared to waiting for events from `SetTimer`. I also refactored code to remove event dispatching from function responsible for waiting for events. This provides more clear separations of concern and avoids unnecessary duplication of dispatching logic. After [review] from @rib, I also moved the waiting itself from `wait_for_messages` method to separate function, so it is clearly seen that `wait_for_messages` do 3 things: notify app that we about to wait, wait, notify that we have new events. I have tested behaviour using a egui app with Vulkan rendering with `VK_PRESENT_MODE_IMMEDIATE_KHR`, and older version consistently have twice less FPS than requested (e.g. 30 FPS when limit is 60 and 60 FPS when limit is 120) while newer version works more correctly (almost always 60 FPS when limit is 60, and only 5-10 frames missing when FPS is set to 120 or more). Fixes https://github.com/rust-windowing/winit/issues/1610 [`CreateWaitableTimerExW`]: https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createwaitabletimerexw [`MsgWaitForMultipleObjectsEx`]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-msgwaitformultipleobjectsex [`SetTimer`]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-settimer [review]: https://github.com/rust-windowing/winit/pull/3950#discussion_r1800184479 |
||
|---|---|---|
| .cargo | ||
| .github | ||
| docs/res | ||
| dpi | ||
| examples | ||
| src | ||
| tests | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| build.rs | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| clippy.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| deny.toml | ||
| FEATURES.md | ||
| HALL_OF_CHAMPIONS.md | ||
| LICENSE | ||
| README.md | ||
| rustfmt.toml | ||
| taplo.toml | ||
| typos.toml | ||
winit - Cross-platform window creation and management in Rust
[dependencies]
winit = "0.30.5"
Documentation
For features within the scope of winit, see FEATURES.md.
For features outside the scope of winit, see Are we GUI Yet? and Are we game yet?, depending on what kind of project you're looking to do.
Contact Us
Join us in our 
room.
The maintainers have a meeting every friday at UTC 15. The meeting notes can be found here.
Usage
Winit is a window creation and management library. It can create windows and lets you handle events (for example: the window being resized, a key being pressed, a mouse movement, etc.) produced by the window.
Winit is designed to be a low-level brick in a hierarchy of libraries. Consequently, in order to show something on the window you need to use the platform-specific getters provided by winit, or another library.
MSRV Policy
This crate's Minimum Supported Rust Version (MSRV) is 1.73. Changes to the MSRV will be accompanied by a minor version bump.
As a tentative policy, the upper bound of the MSRV is given by the following formula:
min(sid, stable - 3)
Where sid is the current version of rustc provided by Debian Sid, and
stable is the latest stable version of Rust. This bound may be broken in case of a major ecosystem shift or a security vulnerability.
An exception is made for the Android platform, where a higher Rust version must be used for certain Android features. In this case, the MSRV will be capped at the latest stable version of Rust minus three. This inconsistency is not reflected in Cargo metadata, as it is not powerful enough to expose this restriction.
Redox OS is also not covered by this MSRV policy, as it requires a Rust nightly toolchain to compile.
All crates in the rust-windowing organizations have the
same MSRV policy.
Platform-specific usage
Check out the winit::platform module for platform-specific usage.