You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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)
The text was updated successfully, but these errors were encountered: