-
Notifications
You must be signed in to change notification settings - Fork 879
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
[iOS] Allow setting up a single UIWindow or UIViewController with either metal or glex context #802
Comments
cc @mtak-. I'd expect this could be handled by adding a |
I ended up browsing iOS open issues to survey them a bit; but I think this issue can be closed since it's actually possible to do this, it's just badly documented (and may have been added after this issue got filed). Call into the
Create a metal enabled UIView like this:
Edit: Just noticed that this doesn't address the specific technical goal in the issue; however it does get to the same goal, of getting metal up and running. |
This will be a requirement for the maplibre-rs project. We do not want to render maps fullscreen but in separate views. We also need handling of inputs. Not just Metal rendering. |
Is there a way to side step Winit application setup for iOS and macOS and just get the building blocks for rendering Metal or openGL/ES?
I can setup the Application from Xcode and then call Rust code from Swift - so Winit can assume an application context is already setup.
All I really need is either a
UIWindow
,UIView
or aUIViewController
from Winit.I did a for where this works, so there is nothing preventing Winit for taking arguments when initialising
let window = winit::Window::new(args... &events_loop).unwrap();
to not setup the application context. In this case aUIApplicationMain
,UIApplicationDelegate
and the other parts that's not necessary.Instead I rather send events down to Winit with some sort of of a push/pump style for application lifecycle.
Still expecting Winit to tackle touches and other window based events.
The issue here is that those events (touches, window) are put on the
UIApplicationDelegate
when setting them on aUIViewController
would suffice.TL;DR would be nice to be able to side step these https://github.com/tomaka/winit/blob/master/src/platform/ios/mod.rs#L367-L368
and also implement the touch & window events on
UIViewController
instead of theUIApplicationDelegate
.For most lifecycle events, there are
NSNotificationCenter
keys that can be used instead.The text was updated successfully, but these errors were encountered: