-
Notifications
You must be signed in to change notification settings - Fork 50
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
Resize the surface at the correct time in examples #236
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does winit
assume (for every backend) / guarantee that a surface
is "always" created with "some" initial size, and always delivers a Resized
event afterwards if it changed? Or otherwise, if it doesn't know/understand/have an initial size, always raises a Resized
event?
Hmm, isn't this more of a Softbuffer issue? We're creating the surface from the window, which itself has an initial size (the examples use |
e44e4c0
to
6bb305f
Compare
It seems a bit surprising that creating a Otherwise that would have been a valid reason to not have size queries on the |
Well, on macOS/iOS at least I think we could fairly easily make the surface follow the size of the window automatically, but I don't know about the other platforms. |
Same on Android, by requesting a buffer size of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but as discussed in #237 (comment) we might want to remove resize()
entirely as this change in particular sets the presedent that the user has to forward the Resized
event from winit
to softbuffer
(which some platforms can handle implicitly by following the window/surface size, or could be useful for explicit hardware scaling).
The examples previously showed resizing just before rendering, which is inefficient, the user should only resize when needed. Tested on macOS.
I have not updated the
winit_multithread
example, as it was a bit more cumbersome, and I wouldn't be able to test it anyways, as it doesn't seem to work on macOS.