Android support for EFrame #1952
Conversation
No worries, thanks for taking a look. Yeah, it's a bit more involved, though hopefully not too unwieldy. There's perhaps also a chance that having a clearer line between app state, render state and window state could help with other things, besides Android, later too - maybe a stepping stone for supporting multiple windows with desktop window systems. |
This enables native applications to add an `event_loop_builder` callback to the `NativeOptions` struct that lets them modify the Winit `EventLoopBuilder` before the final `EventLoop` is built and run. This makes it practical for applications to change platform specific config options that Egui doesn't need to be directly aware of. For example the `android-activity` glue crate that supports writing Android applications in Rust requires that the Winit event loop be passed a reference to the `AndroidApp` that is given to the `android_main` entrypoint for the application. Since the `AndroidApp` itself is abstracted by Winit then there's no real need for Egui/EFrame to have a dependency on the `android-activity` crate just for the sake of associating this state with the event loop. Addresses: emilk#1951
Conceptually the Winit `Resumed` event signifies that the application is ready to run and render and since rust-windowing/winit#2331 all platforms now consistently emit a Resumed event that can be used to initialize graphics state for an application. On Android in particular it's important to wait until the application has Resumed before initializing graphics state since it won't have an associated SurfaceView while paused. Without this change then Android applications are likely to just show a black screen. This updates the Wgpu+Winit and Glow+Winit integration for eframe but it's worth noting that the Glow integration is still not able to fully support suspend and resume on Android due to limitations with Glutin's API that mean we can't destroy and create a Window without also destroying the GL context, and therefore (practically) the entire application. There is a plan (and progress on) to improve the Glutin API here: rust-windowing/glutin#1435 and with that change it should be an incremental change to enable Android suspend/resume support with Glow later. In the mean time the Glow changes keep the implementation consistent with the wgpu integration and it should now at least be possible to start an Android application - even though it won't be able to suspend correctly. Fixes emilk#1951
|
I just pushed a change to remove a redundant |
|
I noticed that the destructor of the app is not called when the app window is closed on Android with this branch. |
|
I also noticed that this currently continuously redraws, which is not the best behavior on a mobile device. |
|
Okey, thanks for experimenting with the branch @Zoxc. At least for the latter I'd figure it might be reasonable to tackle that as an orthogonal follow up issue (unless its affecting other platforms), and for the first one we should at least double check things are cleaning up correctly e.g for Windows - to check this doesnt regress somthing. I have seen issues with wgpu resource cleanup with egui before on Windows (non-eframe) so would be curious if thats related to this deferred initialization pattern somehow. I might not get around to testing for some days I guess so if you manage to figue out any more details it would be great to hear what you find from experimenting @Zoxc |
This continues the work I started in #1634 by updating eframe to also defer how it initializes graphics state, which ensures that on Android we wait until the application has an associated
SurfaceView.The first commit (which affects the
NativeOptionAPI) is needed for me to use the android-activity Android glue crate with Egui which was a pre-requisite for being able to create an Android test/example using eframe. Notably; the aim here was to create a general mechanism that allows customizing the event loop so it's not necessary for Egui/EFrame to have a direct dependency on theandroid-activityglue crate (since Winit will generally handle the Android platform integration).The minimal example here can be used to test this - and that will hopefully be updated soon to use demo lib.
The main issue hit while making this change was realizing that it was only really possible to support Android fully with Wgpu currently, not with Glow/Glutin.
The difficulty with Glutin is that it currently tightly couples a GL context with a window which means you can't destroy and recreate just the window surface when an Android app is suspended - you're forced to also destroy the full GL context, at which point you're basically forced to tear everything down. There is work in progress to improve the Glutin API so suspend and resume will be possible to support in the future, but I'm not sure what the eta is currently for this work.
For now though I have still updated the Glow integration in-line with the Wgpu changes - so it would be possible to launch an Glow based application on Android and it should work until the application is suspended - which is at least an incremental improvement and hopefully it will just be another incremental change to support suspend and resume once the
SurfaceAPI lands for Glutin.Closes #1951