Android support for EFrame, including support for suspend + resume events #1951
Labels
bug
Something is broken
Comments
rib
added a commit
to rib/egui
that referenced
this issue
Aug 21, 2022
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
rib
added a commit
to rib/egui
that referenced
this issue
Aug 21, 2022
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
rib
added a commit
to rib/egui
that referenced
this issue
Aug 21, 2022
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
rib
added a commit
to rib/egui
that referenced
this issue
Aug 21, 2022
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
rib
added a commit
to rib/egui
that referenced
this issue
Aug 21, 2022
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
rib
added a commit
to rib/egui
that referenced
this issue
Aug 21, 2022
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
emilk
pushed a commit
that referenced
this issue
Aug 23, 2022
* eframe: allow hooking into EventLoop building 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: #1951 * eframe: defer graphics state initialization until app Resumed 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 #1951
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
As a continuation of the work started with #1634 it would also be good to update EFrame to be able to defer the initialization of render state until the app is first resumed (and be able to re-create windows/surfaces for further Suspend/Resumed events) so that EFrame can be used to build Android applications.
Right now if you try and run an EFrame based application on Android you will simply get a black screen.
To Reproduce
The Android example here can potentially be used to reproduce this: https://github.com/rib/android-activity/tree/eframe/examples/agdk-eframe - though there's a chicken / egg situation since that test has actually been updated to work with a branch I will submit as a PR soon.
Expected behavior
It should be possible to run an eframe application on Android with input handling and correct rendering, as well as be able to suspend and resume when switching between applications.
The text was updated successfully, but these errors were encountered: