Decouple glutin from winit #1435
Merged
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
MarijnS95
reviewed
Aug 2, 2022
|
I could probably do the macOS and iOS impls |
|
I'm not quite sure how I keep the Api, but ios impl would be very welcome, since I don't really mind doing macOS one. |
'aight, I think I'll wait until you have progressed further. I have to get a newer device set up anyhow, which will take a little while. While I can (since #1441) run |
kchibisov
force-pushed
the
glutin-v2
branch
3 times, most recently
from
525062b
to
9c01848
Compare
|
I've pushed one more update and kind of settled on the final Api I want to use. The current version has stabs for macOS/Wgl with In general once feeling the All the |
|
@madsmtm added macOS support, but something maybe missing here and there. Had to adjust Api a bit for it to work but at least example should show window. Also I have no clue how to do error handling on it. With |
i509VCB
reviewed
Aug 19, 2022
|
Just made a first pass through the changes here and they definitely look like a good direction from my pov, while I'm currently stuck with being able to update the Intuitively this is more the kind of design I had been expecting to find with a separate Surface type and then having |
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 20, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support Android due to limitations in with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly.
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support Android due to limitations in with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly.
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support Android due to limitations in with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly.
i509VCB
reviewed
Aug 21, 2022
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support Android due to limitations in with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly.
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support suspend and resume on Android due to limitations with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore (practically) the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android suspend/resume support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly.
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support suspend and resume on Android due to limitations with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore (practically) the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android suspend/resume support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly.
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support suspend and resume on Android due to limitations with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore (practically) the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android suspend/resume support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly.
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support suspend and resume on Android due to limitations with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore (practically) the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android suspend/resume support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly. Fixes emilk#1951
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support suspend and resume on Android due to limitations with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore (practically) the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android suspend/resume support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly. Fixes emilk#1951
rib
added a commit
to rib/egui
that referenced
this pull request
Aug 21, 2022
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support suspend and resume on Android due to limitations with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore (practically) the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android suspend/resume support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly. Fixes emilk#1951
i509VCB
reviewed
Aug 21, 2022
glutin/src/platform/x11.rs
Outdated
| /// | ||
| /// This must be used when building X11 window, so it'll be compatible with the underlying Api. | ||
| pub struct X11VisualInfo { | ||
| display: *mut Display, |
There was a problem hiding this comment.
How do we assert the display is valid for the lifetime of the visual info?
There was a problem hiding this comment.
That's the problem in general with RawDisplayHandle, since it could in theory be dropped. We could open inner connection and has our own XDisplay. I'm actually not entirely sure how to handle that other than open another connection?
i509VCB
reviewed
Aug 21, 2022
This was referenced Sep 3, 2022
Closed
Closed
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.
Thit commit removes direct dependency on the winit and
using raw_window_handle crate instead
--
This is a draft for now given that macOs and Windows support is missing(and also ios, but I don't have a way to add it anyway). The examples are also lacking. However the public Api are unlikely to change (besides adding more config options).
The feedback is welcome!