Platform API is tricky to use on mobile about egui_winit_platform HOT 4 OPEN

If you can find a way to make it more consistent to use, then that would be fine. Maybe have a look at the upstream winit integration and look for inspiration there.

from egui_winit_platform.

Ahh, hmmm, I hadn't realised there was separate, upstream support for winit :/

I wonder if it could be good to add some sign posting to the README, maybe explaining what the differences are? Was this project maybe created before there was upstream support?

from egui_winit_platform.

This project provided winit support before upstream decided to write their own integration. I don't really feel like doing comparisons, since this project is mainly driven by the community and their needs. As long as people provide patches for this crate, since they seem to continue using it, they will get merged and this crate keeps getting maintained.

from egui_winit_platform.

Okey, right, makes sense, thanks for the info.

Modulo any kind of technical comparison it might still be helpful to sign post in the README that there's also an upstream Winit backend now, just to help people be aware and make a more informed decision about which one fulfills their needs best. I suppose I didn't look very thoroughly but when I searched for a winit backend I only found this project and didn't realise there was an alternative.

Just taking a look at the upstream integration, re: this particular issue it looks like it essentially has a similar awkwardness in that you need to pass a Window into the State::new() API (equivalent to Platform::new() and because it caches the pixels_per_point without any explicit way to update then it would also be necessary to submit a fake ScaleFactorChanged each time we get a new Window on Android.

One thing that is notable though is that the RawInput is retrieved before each execute() via a take_egui_input() api that actually takes a Window reference which is used to query the window size for RawInput. So with that library it might be possible to also use that opportunity to re-sync the scale_factor from the Window too but I'm not sure about that, considering how the scale_factor is also required for input handling - I think there would still be a bit of a race condition without another api like set_window() or maybe window_changed().

Considering the scale_factor, it looks like the upstream logic also tries to differentiate the current_pixels_per_point from the RawInput pixels_per_point to somehow account for applications wanting to scale the UI (which is something I'm currently trying to figure out how to handle while the UI on my phone by default is far too tiny to practically use when only taking into account the Window scale_factor.)

It could be good if there was a clear distinction between an application scale factor and the current window scale factor, so there would maybe be a Platform::window_changed() method for keeping the window size + scale_factor in sync internally and a Platfom::set_scale() for the application to be able to influence further scaling of the UI. Internally the final pixels_per_point would be calculated as window.scale_factor() * app_scale_factor.

from egui_winit_platform.