egui_winit/wgpu: enable Android support #1634
Conversation
The functionality found in egui_winit_platform and egui_wgpu_backend is now available in the upstream egui-winit and egui-wgpu crates respectively. This has simplified the example itself and also removed the dependency on epi. The example is now based on egui 0.18 (was previously 0.17) Since the upstream egui-winit/wgpu crates were generally assuming that the graphics context and surface can be initialized immediately this currently builds against a branch that aims to upstream changes that remove these assumptions: https://github.com/rib/egui/tree/android-deferred-winit-wgpu Ref: emilk/egui#1634
|
If we're changing the |
|
yeah, sounds good, it was fairly arbitrary that I just exposed the power preference and present mode |
In this case I added the FiXMEs to code where I was maintaining status quo (where it wont currently work on Android) but I had to make integration changes to use the updated egui_wgpu and egui_winit API. My intent was to just focus first on supporting Android better via egui_winit + egui_wgpu directly (i'm not cuurently using eframe) but I figured it was worth highlighting where the current integration details for epi / eframe aren't portable to Android. I can try to take another pass later to also support Android via epi / eframe by addressing the FIXMEs, but would it be ok perhaps to leave them for this PR? Or perhaps just remove for cleaner aesthetics? |
3c60969 to
bce303f
Compare
With the updated patches I've just pushed the |
On Android in particular we can only initialize render state once we have a native window, after a 'Resumed' lifecycle event. It's still practical to be able to initialize an egui_winit::State early on so this adds setters for the max_texture_side and pixels_per_point that can be called once we have a valid Window and have initialized a graphics context. On Wayland, where we need to access the Display for clipboard handling we now get the Display from the event loop instead of a window.
Enable the renderer and surface state initialization to be deferred until we know that any winit window we created has a valid native window and enable the surface state to be updated in case the native window changes. In particular these changes help with running on Android where winit windows will only have a valid native window associated with them between Resumed and Paused lifecycle events, and so surface creation (and render state initialization) needs to wait until the first Resumed event, and the surface needs to be dropped/recreated based on Paused/Resumed events.
bce303f to
e75ac2b
Compare
The functionality found in egui_winit_platform and egui_wgpu_backend is now available in the upstream egui-winit and egui-wgpu crates respectively. This has simplified the example itself and also removed the dependency on epi. The example is now based on egui 0.18 (was previously 0.17) Since the upstream egui-winit/wgpu crates were generally assuming that the graphics context and surface can be initialized immediately this currently builds against a branch that aims to upstream changes that remove these assumptions: https://github.com/rib/egui/tree/android-deferred-winit-wgpu Ref: emilk/egui#1634
I've recently been looking at using egui to create an Android app that I can use to test a Bluetooth library that I'm building but I found that it would panic due to some assumptions that it's possible to access a native window for initializing render + surface state while the application is paused.
This implements the proposal in #1633 which enables graphics state to be lazily initialized on Android when the application is Resumed (at which point it has a valid native window) as well as support dropping/recreating surface state each time the application is paused/resumed on Android.
Since I'm currently using
egui_winitandegui_wgpudirectly this PR only focuses on enabling Android support via these APIs. The corresponding epi/glium changes adapt to the egui_wini/wgpu API changes but have some remaining assumptions about when a window is valid which means they would require some further work to add Android support.Closes #1633.