Comments (8)
cc @mtak-. You've got experience with iOS - what's your take on this?
from raw-window-handle.
There are two paths that hal uses on iOS for the CAMetalLayer
setup.
-
If the
UIView
's-[UIView layer]
is aCAMetalLayer
, then hal will use the existing layer, and everything will work great. hal usesisKindOfClass
to detect whether the layer is aCAMetalLayer
. -
If the
layer
is not aCAMetalLayer
, thenhal
adds aCAMetalLayer
sublayer to that layer. It then has some workarounds to resize the layer when the swapchain is created - whereas with the first option there are no workarounds, and things tend to work a bit better.
I strongly recommend the first option, and I personally think hal should panic if the layer isn't a CAMetalLayer
.
from raw-window-handle.
I think it makes sense for iOS and macOS to have a pointer to the CALayer
inside of the raw-window-handle.
from raw-window-handle.
Could we rename the topic towards sth like: MacOS/IOS Interface
?
Current interfaces:
pub struct MacOSHandle {
pub ns_window: *mut c_void,
pub ns_view: *mut c_void,
}
pub struct IOSHandle {
pub ui_window: *mut c_void,
pub ui_view: *mut c_void,
pub ui_view_controller: *mut c_void,
}
The graphics APIs (Metal and Vulkan Portability) expect a CAMetalLayer
in their window system interface. Earlier MoltenVK versions exposed an API surface taking NSView/UIView. Are there other relevant graphics APIs which communicate with the views/windows?
At the end of the day I guess it boils down which side (window <-> graphics api) has to do potential conversion steps.
from raw-window-handle.
So when trying to implement this for beryllium yesterday (SDL2 based lib) I was able to get an NS_Window from SDL2 but it doesn't give an NS_View.
Is this field required? Seems like no, because the mac folks told me you can always get a view from the window pointer.
Should we change the Mac handle to be an Option<NonNull<c_void>> with the None version more clearly meaning "get the default yourself" and the Some version being "use this specific sub-view here".
from raw-window-handle.
@Lokathor There are some fields on other platforms with similar-ish semantics (e.g. hinstance
on Windows). I'm more inclined to add the following language to the root HasRawWindowHandle
docs:
/// It is entirely valid behavior for fields within each platform-specific `RawWindowHandle` variant
/// to be `null` or `0`, and appropriate checking should be done before the handle is used. However,
/// users can safely assume that non-`null`/`0` fields are valid handles, and it is up to the
/// implementor of this trait to ensure that condition is upheld.
///
+/// Still, implementors should make a best-effort attempt to fill in all available fields. If an
+/// implementation doesn't, and a downstream user needs the field, it should try to derive the
+/// field from other fields the implementor *does* provide via whatever methods the platform
+/// provides.
+///
/// The exact handle returned by `raw_window_handle` must not change during the lifetime of this
/// trait's implementor.
pub unsafe trait HasRawWindowHandle {
fn raw_window_handle(&self) -> RawWindowHandle;
}
from raw-window-handle.
If I'm understanding this right, this will be fixed by #129
from raw-window-handle.
#129 is merged so this issue should now be fixed.
from raw-window-handle.
Related Issues (20)
- Type-system relationship between `HasRaw*Handle` and `Has*Handle` traits HOT 3
- Does `RawWindowHandle` need to be `Copy`? HOT 3
- Should X display/connection handles be nullable? HOT 4
- Proposal: Remove `Copy` from `RawDisplayHandle` HOT 3
- Proposal: Make the error type implementor-selectable? HOT 2
- Follow the Rust API Guidelines HOT 2
- Take `self` instead of `&self` in raw window handles? HOT 9
- Figure out missing display handle implementations HOT 6
- Add tests for Rust subleties HOT 2
- Add relevant categories to `Cargo.toml`
- Improve documentation
- Question: Why are we exposing canvas elements instead of just any node? HOT 2
- What is the right way of handling web handles? HOT 2
- Add a bitset that allows libraries to state what types of raw window/display handles are supported HOT 1
- Add safe constructors for display and window handles HOT 3
- Remove `WebWindowHandle`? HOT 2
- Make safe `WindowHandle` s to imilictly ref-count HOT 27
- Info about sdl HOT 2
- Support DirectFB in RawWindowHandle and RawDisplayHandle? HOT 1
- Change Windows `HANDLE` types back to `*mut c_void` **again** :weary:? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from raw-window-handle.