egui-winit: Receive window scale factor and size via events #7760
+105
−97
Conversation
This file contains hidden or 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
|
Preview available at https://egui-pr-preview.github.io/pr/7760-winit-fix-window-size-inconsistency View snapshot changes at kitdiff |
MarijnS95
force-pushed
the
winit-fix-window-size-inconsistency
branch
from
1676c48 to
402e239
Compare
MarijnS95
commented
Dec 8, 2025
crates/egui-winit/src/lib.rs
Outdated
| .get(&self.viewport_id) | ||
| .expect("No viewport") | ||
| .native_pixels_per_point | ||
| .expect("ScaleFactorChanged must have been raised") |
Contributor
Author
There was a problem hiding this comment.
On the pure_glow example on Wayland we seem to receive Resized -> RedrawRequested -> ScaleFactorChanged.
This'll panic because they're out of order, and we might need to make sure to update the input size again also when the scale factor changes.
We found in our application (with custom `egui` renderer) that the `screen_rect` in `RawInput` was mismatching with the `winit` events that we processed earlier (in particular on resize on MacOS, which raises a lot of small size changes). One of the contributing factors was `egui-winit` reading the `Window` size and scale factor over and over again separate from processed events, causing a mismatch on some platforms because this value would already change ahead of consuming a `Resized` event. Secondly, some existing event processing may rely on this value being consistent with the event stream. There is currently no guarantee -at least I don't see it in the documentation- that `winit` ensures that `inner_size()` will always return a consistent value until the user has consumed a `Resized` event. This gets worse when certain functions (like `update_viewport_info()`) are possibly called on a separate thread because both `egui::Context` and `winit::Window` are thread-safe. Those also have an extra draw-back of roundtripping to the event loop on the main thread to query these values, as a `Window` is not actually thread-safe on all platforms.
MarijnS95
force-pushed
the
winit-fix-window-size-inconsistency
branch
from
402e239 to
8b30dde
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
We found in our application (with custom
eguirenderer) that thescreen_rectinRawInputwas mismatching with thewinitevents that we processed earlier (in particular on resize on MacOS, which raises a lot of small size changes).One of the contributing factors was
egui-winitreading theWindowsize and scale factor over and over again separate from processed events, causing a mismatch on some platforms because this value would already change ahead of consuming aResizedevent. Secondly, some existing event processing may rely on this value being consistent with the event stream.There is currently no guarantee -at least I don't see it in the documentation- that
winitensures thatinner_size()will always return a consistent value until the user has consumed aResizedevent. This gets worse when certain functions (likeupdate_viewport_info()) are possibly called on a separate thread because bothegui::Contextandwinit::Windoware thread-safe.Those also have an extra draw-back of roundtripping to the event loop on the main thread to query these values, as a
Windowis not actually thread-safe on all platforms.This is still opened as a draft because it has not been tested on all platforms, and there are far more odd calls to
window.inner_size(),window.outer_size()andwindow.scale_factor()than anticipated which might all suffer from the same behaviour; not all immediately have access to the latest state inRawInputthough.Secondly it was surprising to see the viewport code that updates
native_pixels_per_pointin a very disconnected way fromRawInput::pixels_per_point, which I'd like to understand better before making any more changes here. It seems like this was already all carefully crafted (ie. #4211) and battle-tested to circumnavigate the inconsistency issues above... 😕