How should users interface with graphics libraries on macOS/iOS? about raw-window-handle HOT 8 CLOSED

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.

1. If the UIView's -[UIView layer] is a CAMetalLayer, then hal will use the existing layer, and everything will work great. hal uses isKindOfClass to detect whether the layer is a CAMetalLayer.

2. If the layer is not a CAMetalLayer, then hal adds a CAMetalLayer 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.