Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

on Android, touch position may not be correctly reported #7528

Open
mockersf opened this issue Feb 6, 2023 · 0 comments
Open

on Android, touch position may not be correctly reported #7528

mockersf opened this issue Feb 6, 2023 · 0 comments
Labels
C-Bug An unexpected or incorrect behavior O-Android Specific to the Android mobile operating system

Comments

@mockersf
Copy link
Member

mockersf commented Feb 6, 2023

One possible issue at the moment is Winit's conflated idea of a Window's "inner" size.

Bevy reads that inner size as a "physical" size and assumes it's the size that a surface should be (e.g that size is passed to wgpu when creating a surface) but conceptually that inner size isn't always the appropriate size to use for allocating a render target.

On Android that "inner" size should probably be the inset size - which would be consistent with how the inner size is the inset size of the content inside a window frame for desktop window system, and would also be consistent with iOS.

On iOS the inner size is the inset size and it's somewhat lucky that it works for Bevy to use the size when creating a surface because it turns out that wgpu will actually ignore the size given when creating a surface and internally it explicitly checks the size of the drawable that the surface is being created for.

On Android if we were to currently report the inner size as the inset size then wgpu would create a surface with the size requested by Bevy and then surface flinger would automagically stretch that surface. (though it sounds like something similar is already happening)

Here's the Winit issue for this: rust-windowing/winit#2308

I had been hoping to get some time to look at that but have recently been bogged down looking at the jni crate which we're probably going to need to start using in Winit's Android backend.

from #7493 (comment)

@mockersf mockersf added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled O-Android Specific to the Android mobile operating system and removed S-Needs-Triage This issue needs to be labelled labels Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Bug An unexpected or incorrect behavior O-Android Specific to the Android mobile operating system
Projects
None yet
Development

No branches or pull requests

1 participant