El2.0 ios

[mtak-]

Here's the EL2.0 implementation for iOS.

@Osspial Sorry for my absence, and thanks for your patience! I have other things I'd rather be spending time on at the moment. I'm not sure if it makes sense for me to still be the iOS backend maintainer, though I'll probably scroll through tickets infrequently.

iOS defaults to fullscreen windows if both dimensions and fullscreen are None which is natural for that platform, but the default window size here annoyingly breaks this. Of course it's easy to workaround by calling with_fullscreen(monitor). Perhaps the default window size should only be provided for desktops?

Let me know if you have questions. Tested on several iOS devices with different dpis and idioms (ipad/iphone).

[goddessfreya]

Thank you!

Shouldn't window not be Send + Sync?

https://www.objc.io/issues/2-concurrency/thread-safe-class-design/

It’s a conscious design decision from Apple’s side to not have UIKit be thread-safe. [...] All you have to do is make sure that calls into UIKit are always made on the main thread.

EDIT: I see you just went through and annotated every function with /// **iOS:** Can only be called on the main thread. I'd rather we only annotate the function that builds the window, and then make the window !Send + !Sync, that way users don't make a mistake.

[mtak-]

@zegentzy I agree it shouldn't be Send+Sync. Currently the iOS backend impls Send+Sync, but asserts that every UIKit method is called from the main thread (unless I missed something!). This was done to maintain the same API on the iOS backend as other backends e.g. if a users code compiles on windows/linux/etc it should also compile on iOS.

I would be in favor of removing the Send + Sync impls on Window because the compile time error is IMO better than a runtime panic even if it fractures the API. What do you think?

It's possible, the UIKit restrictions could be worked around with GCD/caching, but that might be fairly tricky to do correctly - tho the macos backend does do this.

[goddessfreya]

I'm not sure what GCD is, but when I skimmed through the macos backend, I didn't spot anything that was stopping it from accessing the NSView from non-main threads, which is why I opened #873 after some discussion with @vberger .

Glutin already assumes users are not going to move the window across threads (with functions like split), and I'd rather it's codified.

If compiling on all platforms is a concern, maybe we could compromise by adding a WindowWrapper type.
Some pseudo code:

pub struct WindowWrapper(Window);

impl Deref for Window {
    fn deref() -> &Window {
        if platform is ios (or macos too?) and not on main thread {
            panic!();
        }
        window
    }
}

This way at least we don't have to go around asserting that every UIKit method is called from the main thread.

[mtak-]

I think the el2.0 macos implementation makes an attempt at thread safety whereas the current version does not.

GCD refers to Grand Central Dispatch. The macos el2.0 implementation uses it here to dispatch state changes to the main thread. Additionally, it checks that window creation happens on the main thread here. I didn't thoroughly review the code to ensure it was used consistently/correctly, but on a first glance, the "getters" look like they would also need routing through GCD to be truly thread safe.

Something like the Deref impl could probably work... I'll look into it.

[mtak-]

@zegentzy Deref was indeed much cleaner/more scalable. Pushed.

[goddessfreya]

This looks great. Hopefully we can get something like this done to the macos backend in an other PR.

[goddessfreya]

Should we go ahead and merge this in @Osspial? Worst case scenario, a slightly-faulty iOS backend is better than none.

[Osspial]

Yep, this looks good! Thanks!