search

rust-mobile / android-activity

Glue for building Rust applications on Android with NativeActivity or GameActivity
251 stars 49 forks source link

click shift on 1080x2400 display #43

Open tkkcc opened 1 year ago

tkkcc commented 1 year ago

agtk-egui

https://user-images.githubusercontent.com/17373509/203543713-e6893c36-cb8b-4aab-9ae3-f2db812a8968.mp4

rib commented 1 year ago

Oh, odd, I don't think I've seen that when I run the same example - but maybe I was testing agdk-eframe more recently.

Thanks for the report.

This is maybe something that should ideally be tracked as either a Winit or an Egui issue but it's probably fine here for now until we determine what the underlying issue really is - considering I've been working on Winit and Android support in Egui too.

I'm not 100% sure when I'll get around to investigating so please post here if you figure out any more clues from experimenting yourself.

It could also be helpful to know whether you see the same thing with agdk-eframe

I wonder if it relates to how DPI scaling is done, and maybe the input is being scaled by the wrong factor (not consistent with how the visuals are scaled by DPI)

At some point I think the example may have had some hacky 2x multiplier for the DPI because the regular DPI scaling was still resulting in an unusably small UI on mobile phones - maybe I left a constant scale factor for rendering in the example that's not also used for input events.

tkkcc commented 1 year ago

It's tested on a poco f3 phone with official system. no mod no root. DPI is 440: Screenshot_2022-11-27-22-51-43-409_com liuzh deviceinfo

agdk-eframe has same problem. egui.rs in webbrowser works fine.

I also tried on genymotion emulators but app stops on boot, logcat shows error about egl.

tkkcc commented 1 year ago

I can reproduce this issue on waydroid on another PC, agdk-eframe with ndk 25.1.8937393 or 24.0.8215888 .

waydroid use 720p 320DPI

~ adb shell wm size
Physical size: 1762x700
Override size: 720x1280
~ adb shell wm density
Physical density: 180
Override density: 320

Cargo.lock

[[package]]
name = "winit"
version = "0.27.2"
source = "git+https://github.com/rib/winit?branch=android-activity#b3ba646fc8b5e1ddcbf8f95f905f0fe809e49a2a"
[[package]]
name = "egui"
version = "0.20.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "egui-winit"
version = "0.20.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "eframe"
version = "0.20.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
MarijnS95 commented 1 year ago

Since there doesn't seem to be an issue horizontally, and the distance between touch input and where the app ends up processing it in window moves and textbox interaction (hard to tell from a minimal video), is this perhaps simply the offset of the titlebar not being taken into account?

rib commented 1 year ago

Sounds very plausible yep. I had started looking at updating the winit backend to add support for querying the surface size distinct from the inner size that would be able to account for insets (re: https://github.com/rust-windowing/winit/issues/2308) and maybe that'll end up helping enable egui to consider insets for a titlebar.

MarijnS95 commented 1 year ago

Yeah it looks very much that this isn't the surface size but the whole window/Activity size. Would be great to have a repro project to validate this theory (again: not visible from a video...), though can probably whip one up easily.

tkkcc commented 1 year ago

add getSupportActionBar().hide(); after hideSystemUI(); can solve this. just remove the native bar.