Winit version 0.30.6 #4042
Open
Winit version 0.30.6 #4042
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
A panic doesn't really put any of the fields in XConnection into an invalid state, so there is no real reason to panic when poisoning is detected. So just ignore the poison. Closes #3870 Signed-off-by: John Nunley <[email protected]>
This makes it so, when X11 fails to initialize due to not loading a library, it provides more verbose information on what exactly happened. Fixes #3883. Signed-off-by: John Nunley <[email protected]> Co-authored-by: Kirill Chibisov <[email protected]>
Co-authored-by: Mads Marquart <[email protected]>
kchibisov
requested review from
jackpot51,
notgull,
madsmtm and
MarijnS95
as code owners
Return error from it instead of unwrapping.
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 #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]: #3950 (comment)
Based on #3973, which should be merged first. There's an API to programmatically specify X11 screen id (override what is determined from the `DISPLAY` env variable), but it doesn't work. Seeting up X Server with 2 screens and calling `DISPLAY=:0 X11_SCREEN_ID=1 cargo run --example window` should be equivalent to calling `DISPLAY=:0.1 cargo run --example window` The latter works (and places the window on the correct screen), but the former yields `failed to create initial window: Os(OsError { line: 620, file: "src/platform_impl/linux/x11/window.rs", error: X11Error(X11Error { error_kind: Match, error_code: 8, sequence: 219, bad_value: 1319, minor_opcode: 0, major_opcode: 1, extension_name: None, request_name: Some("CreateWindow") }) })` _Here `1319` is the root window id for screen 0, which doesn't match the screen 1 that we request._ The problem is that we need to factor in the screen id when determining the parent (root) window when not explicitly set. This patch does that. --- Also: Extend the window example with X11_{SCREEN,VISUAL}_ID env variables
This is not strictly required, but makes the examples a bit easier to read understand (especially since the `EventLoop` really _should_ be created inside `fn main`, and not in some random function potentially running on a random thread).
Route it via the `Window::set_ime_allowed` like on iOS.
This implements basic iOS IME support (typing, backspace, support for emojis etc but no autocomplete or copy / paste menu). Co-authored-by: Mads Marquart <[email protected]>
It should be done before mapping the window, or we could lose the firsst XInput2 events, such as the first FocusIn. Fixes #2841.
Events emitted by `flagsChanged:` cannot access `charactersIgnoringModifiers`. We were previously doing this because we were trying to re-use the `create_key_event` function, but that is unsuited for this purpose, so I have separated the `flagsChanged:` logic out from it.
`AnyClass::responds_to` delegates to `class_respondsToSelector`, a function provided by the Objective-C runtime. However, at some point, this began to return `false` for selectors referring to undocumented cursors, despite the cursors remaining accessible via said selectors. That this check fails prevents the cursors from being used. We can instead send `respondsToSelector:` to the `NSCursor` class itself. As an instance method, this is nominally impossible; however, Apple grants an exemption[1] that permits class objects to perform instance methods defined in the root class. Checking for the undocumented cursors in this way gets them working again, at least on macOS Sequoia 15.1.1. [1]: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-TPXREF120
kchibisov
force-pushed
the
release-0306
branch
2 times, most recently
from
7858aab to
eeff36a
Compare
Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: daxpedda <[email protected]>
kchibisov
force-pushed
the
release-0306
branch
from
eeff36a to
4743c3a
Compare
kchibisov
force-pushed
the
release-0306
branch
from
4743c3a to
74bc57a
Compare
madsmtm
approved these changes
Dec 16, 2024
There was a problem hiding this comment.
I'm happy as long as the stuff in the milestone is here (which it seems to be), so 👍 from me.
I actually thought I set #4035 to that as well, but I seem to have set it to v0.31.0, not sure now though, I'll let you decide if you wanna try integrate it.
MarijnS95
reviewed
Dec 17, 2024
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.
--
@madsmtm I've excluded a bunch of recent PRs for macOS, except the capslock one, since I'm not entirely sure whether they are relevant for a patch release.
If I've missed something let me know.