-
Notifications
You must be signed in to change notification settings - Fork 7
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
Upgrade raw-window-handle to 0.6.0 #8
Conversation
There is no longer an `ns_window` member in the new handles, so support for it had to be dropped. At the same time the `ns_view` members are appropriately marked `NonNull<>` so there's no longer a need for this fallback path.
pub enum Layer { | ||
Existing(CAMetalLayer), | ||
Allocated(CAMetalLayer), | ||
None, | ||
} |
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.
In ash-window
we have a pattern that takes out the CAMetalLayer
. Is there any significance here (e.g. lifetimes) or can we flatten this, store existing vs allocated in a separate member, or add a helper fn value(self) -> CAMetalLayer
thing?
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.
The CAMetalLayer
may be allocated in case there couldn't be extracted one from the window handle, and should be destroyed if not needed anymore (on surface destruction). To not leak the consumer should execute sth like msg_send![layer, release]
in case of Layer::Allocated(layer)
(but couldn't test due to lack of hw)
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.
Since raw-window-metal
maps this nicely, should it also implement Drop
that does this for Allocated
but not for Existing
? Or at least add a doc-comment and perhaps make this an "implementation detail" unless transferring ownership is a thing, which we should make more explicit to the caller?
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.
I could test these things out soon™, perhaps worth doing that before cutting a new release?
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
@@ -1,4 +1,4 @@ | |||
#![cfg(any(target_os = "macos", target_os = "ios"))] | |||
// #![cfg(any(target_os = "macos", target_os = "ios"))] |
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.
Oops, I think I forgot to drop this even after cross-compiling/building/testing to the right target 😅
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8
* ash-window: Upgrade to raw-window-handle 0.6.0 This is the successor to #795. While it doesn't tackle things like backwards-compatibility nor use of the new lifetimed handles (if we _can_ even come up with a safe abstraction for them - it's very likely out of scope!), it includes the following improvements: - Upgrade `raw-window-metal` via [#8] (Mac/iOS wasn't tested in our CI); - Fix Windows platform types (in the `ash` crate) to be `isize` instead of `*const c_void`, matching the usptream definition; - Update example code (impossible until `winit` with `raw-window-handle 0.6` becomes available). [#8]: rust-windowing/raw-window-metal#8 * ash-window/examples/winit: Demonstrate proper surface lifetime with `Suspended`/`Resumed` events
There is no longer an
ns_window
member in the new handles, so support for it had to be dropped. At the same time thens_view
members are appropriately markedNonNull<>
so there's no longer a need for this fallback path.