How should users interface with graphics libraries on macOS/iOS?

[seivan]

Say I create the iOS struct, pass in pointers to UIView alone, without the rest - because technically they would be unnecessary and unused.

How would gfx-hal know wether or not they need to setup things for Metal vs the UView containing a CAMetalLayer and etc?

To clarify, there is no indication mentioned whether or not the related graphics stuff has been setup before hand (e.g using SDL2 to set everything up) vs expecting gfx-hal to create the necessary contexts and CAMetalLayer?

[Osspial]

cc @mtak-. You've got experience with iOS - what's your take on this?

[mtak-]

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.

[mtak-]

I think it makes sense for iOS and macOS to have a pointer to the CALayer inside of the raw-window-handle.

[msiglreith]

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.

[Lokathor]

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".

[Osspial]

@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;
 }

[notgull]

If I'm understanding this right, this will be fixed by #129

[notgull]

#129 is merged so this issue should now be fixed.