-
Notifications
You must be signed in to change notification settings - Fork 50
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
android build instantly exits while windows build runs just fine winit backend #2
Comments
Probably the first thing to check is whether you have pulled the latest repo changes. In particular, hopefully you have this patch: commit 3f1e6ced43879f8294beae95290875c37b85291c
Author: Robert Bragg <[email protected]>
Date: Fri May 20 01:46:54 2022 +0100
GameActivity PATH: fix for checking history pointer samples (without that, there was a bug that would cause lots of crashes) I pushed a bunch of other changes yesterday related to being able to support |
i've pulled the latest changes, and the issue still exists |
Okey, curious. Can you maybe push your changes to branch on a forked repo perhaps, just to make it easier for me to fetch and try running? Just in case it's an issue with how vulkan is used within wgpu, I would also recommend downloading the Vulkan validation layer for Android here: https://github.com/KhronosGroup/Vulkan-ValidationLayers/releases (unpack and place under Have you seen anything in your |
https://github.com/tshrpl/agdk-rust-by-rib/tree/issue_2/examples i have added two apps in the examples folder, these also have a NOTES.md file with the adb logcat output adding the "Vulkan validation layer" files didn't result in any new errors |
Aah, I hadn't taken it in properly when you originally said the issue showed up when you changed the device orientation. okey, yeah there's probably going to be some fiddly things to consider here. On Android when you change orientation then by default it will actually completely destroy your current Activity which is going to cause havoc here. I think there are some config options that can be put in the AndroidManifest that can be used to tell Android not to destroy the activity for an orientation change. I'll have a quick look to see if I can dig up the info for that. |
also, the second example only has an empty winit window (without any vertex buffer) but it exits instantly |
One thing we can try is adding something like this to the <activity android:name=".MyActivity"
android:configChanges="orientation|screenSize|screenLayout|keyboardHidden"
android:label="@string/app_name"> (That should tell Android that the application will handle the config change via |
how can i set it to always be in landscape mode, this way i dont have to handle the orientation changes |
Ah, okey for your On Android we have to wait until the application is This is the main challenge currently with writing Winit applications that are portable between Android and desktop because Winit's API design doesn't naturally lead to portable code and it's very common to find examples that do exactly the same as what you have done here, which is to try and initialize all your graphics state at the start of the program at the same time as creating the event loop. Somehow you need to defer the creation of your render state and surface until you get a |
For some reason the This is the change i tried in case you want to see if it helps for you though: diff --git a/examples/agdk-winit-wgpu-try-1/app/src/main/AndroidManifest.xml b/examples/agdk-winit-wgpu-try-1/app/src/main/AndroidManifest.xml
index 42ef1ea..d0f559a 100644
--- a/examples/agdk-winit-wgpu-try-1/app/src/main/AndroidManifest.xml
+++ b/examples/agdk-winit-wgpu-try-1/app/src/main/AndroidManifest.xml
@@ -11,6 +11,7 @@
android:theme="@style/Theme.RustTemplate">
<activity
android:name=".MainActivity"
+ android:configChanges="orientation|screenSize|screenLayout|keyboardHidden"
android:exported="true">
<intent-filter>
<action android:name="android.intent.action.MAIN" /> I think there is a way to disable orientation changes entirely and force landscape, but not sure off the top of my head. |
|
Ah, that's good to know - yeah I should update the |
hey, i made some changes to |
One thing I just saw from skimming the code is that here: Event::Suspended => {
let mut guard = app.write().unwrap();
guard.render_state = None;
}, you should be able to get away with just dropping your surface state, you don't have to drop all your render state on suspend. I guess that's not the problem you're seeing though. |
ah, interesting, it's panicking here: Event::RedrawEventsCleared => {
let mut guard = app.read().unwrap();
guard.surface_state.as_ref().unwrap().window.request_redraw(); // <--- this line
}, but I wonder if maybe the winit backend shouldn't be sending |
The docs for that event currently say: /// Emitted after all `RedrawRequested` events have been processed and control flow is about to
/// be taken away from the program. If there are no `RedrawRequested` events, it is emitted
/// immediately after `MainEventsCleared`.
///
/// This event is useful for doing any cleanup or bookkeeping work after all the rendering
/// tasks have been completed.
RedrawEventsCleared, so it seems to suggest that it should be sent even if your app didn't get any redraw requests, but I do wonder if it would maybe better for Winit to not send that if there were no redraw events. I suppose for now you need to be cautious to consider that |
okay, i didn't find any other way so i just removed it |
Yeah, it's a pretty big pain getting backtraces for Rust panics on Android atm unfortunately. I need to write this up somewhere for more people I think but this is what works for me atm: Firstly if you scrape your adb log after a panic you should be able to find a (useless looking) backtrace like this:
In my case I grab the backtrace via Android Studio just because that's what I happen to use to run stuff on Android Note: you won't see the backtrace like this if you filter by the application because it's actually a system process that recognises the process has crashed and automatically outputs a stack trace I copy that and save it into a file name Then I have a python script like this: #!/usr/bin/python3
import sys
import re
for line in sys.stdin:
search = re.search('#[0-9]+ +pc +([0-9A-Fa-f]+) +', line)
if search != None:
print(search.group(1)) (I actually added this to the git repo by mistake so you can find it here: https://github.com/rib/agdk-rust/blob/main/examples/na-mainloop/android-addr2line.py) and if run like this:
Those number can then be passed to a tool that comes with the NDK called Assuming you have $ANDROID_NDK_ROOT (or _HOME) setup in your environment to point to your NDK then you can find this tool under
The last thing you need is the libmain.so library that still has your debug symbols (normally the library that's packaged in your apk will have symbols stripped otherwise it would be huge to upload). If you're building libmain.so with cargo ndk then you should still have your unstripped library under So in the end I run a command like: (swap windows-x86_64 for linux-x86_64 if on Linux) and I get a (not very nicely formatted) backtrace with filenames, function names and symbols like this:
So mainly in summary:
Hopefully that procedure can work for you too. At some point it could be good to write a smarter python script that would probably deal with running addr2line and also format the output a bit better too. |
Just to add: in terms of filtering the adb log, I guess you could filter by the error level to be able to get the backtrace from the system but avoid most other spam. (the stack trace is logged by Android as an error) |
i have made a small utility to make debugging a bit easier for myself |
ah, cool I'll have to give your tool a try next time I'm dealing with a panic - thanks for sharing! have you ruled out some kind of initial bug with the input scraping that maybe messes with the offsets sometimes so you then wouldn't always get good results from addr2line? do you maybe also see the same issue when you capture the backtrace with the more manual steps? I might have just been lucky but so far I haven't seen addr2line be unreliable - mainly just cumbersome and hard to read. |
i get the bad traces even when doing everything manually so it's not the tool i just noticed now that your stacktrace has different formatting than mine so you may have to change |
strange, i observed that only 1 frame is drawn in my example |
Curious. It looks like you have also commented out the code that requests a redraw?: https://github.com/tshrpl/agdk-rust-by-rib/blob/61536b5f677d74d6c936a7fa936285069a98d3d8/examples/agdk-winit-wgpu-try-2/src/lib.rs#L528 |
Ah, right you said you just commented out that code to avoid the panic. I think maybe you either need to make it first check if you have a surface and still request a redraw, or else just request the redraw at the end of each redraw (i.e end of |
Event::RedrawRequested(_) => {
(..)
guard.surface_state.as_ref().unwrap().window.request_redraw();
} adding the above did nothing, but adding an if check inside Event::RedrawEventsCleared => {
let mut guard = app.read().unwrap();
if let Some(surface_state) = &guard.surface_state {
guard.surface_state.as_ref().unwrap().window.request_redraw();
}
} |
ah, that's interesting. I should have a look at why it didn't work to request the redraw as part of the |
Sorry for the noise here. I haven't had a chance to look at this specifically yet, though I did do a bunch of work to create a common I'm going to close this issue since I think we resolved the original problem, and I'll open a new issue for the last observation about For now the updated winit backend almost certainly still has this same issue, since it hasn't really changed much, but hopefully I can investigate this soonish |
sorry to bug you again, but i'm completely stuck on this
when i added a vertex buffer to the
agdk-winit-wgpu
example, it ran on windows but on resizing, the window lagged, and on android it stopped responding when trying to change the device orientationcode
shader
so i tried to make a simplified version which runs on windows but instantly exits on android
code
can you please take a look at the (second) code and tell me what am i missing ?
The text was updated successfully, but these errors were encountered: