| Summary: | Android application constantly jumps up and down | ||
|---|---|---|---|
| Product: | SDL | Reporter: | someuniquename |
| Component: | *don't know* | Assignee: | Sylvain <sylvain.becker> |
| Status: | WAITING --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | critical | ||
| Priority: | P2 | CC: | icculus |
| Version: | 2.0.10 | ||
| Hardware: | ARM | ||
| OS: | Android (All) | ||
|
Description
someuniquename
2019-06-23 09:29:06 UTC
The same issue exists in SDL 2.0.9 device: zte nubia z11 mini Android 5.1.1 V/SDL (25270): Device: NX529J V/SDL (25270): Model: NX529J V/SDL (25270): Window size: 1080x1920 V/SDL (25270): Device size: 1080x1920 I/python (25270): [INFO ] [GL ] Using the "OpenGL ES 2" graphics system I/python (25270): [INFO ] [GL ] Backend used <sdl2> I/python (25270): [INFO ] [GL ] OpenGL version <b'OpenGL ES 3.1 V@124.0 (GIT@I041b18199e)'> I/python (25270): [INFO ] [GL ] OpenGL vendor <b'Qualcomm'> I/python (25270): [INFO ] [GL ] OpenGL renderer <b'Adreno (TM) 405'> I/python (25270): [INFO ] [GL ] OpenGL parsed version: 3, 1 I/python (25270): [INFO ] [GL ] Texture max size <16384> I/python (25270): [INFO ] [GL ] Texture max units <16> sample c code to reproduce the issue: https://gist.github.com/Fak3/12a0c6a9f4de38096c0e4761aef742bd The key is to have both multisampling and SDL_WINDOW_FULLSCREEN flag. Sometimes app starts normally, sometimes it jumps. Jumps seem to sometimes go away when app minimized and then maximized. Wrapped sdl calls with Android activity locks, but this bug still exists Can't reproduce with your apk can you add traces in SDLActivity.java I'd say here, when receiving the: COMMAND_CHANGE_WINDOW_STYLE https://hg.libsdl.org/SDL/file/d3a97780aa05/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java#l594 Added trace, full log: https://gist.github.com/Fak3/adefb533e80f95fd8e0befd3d18563b1 COMMAND_CHANGE_WINDOW_STYLE is received couple of times, but then silence in the log and app jumps like crazy. I am able to reproduce it almost every time (80% of app starts) on ZTE nubia z11 mini, Android 5.1 Just wondering: - does it really need the MULTISAMPLE to be set ? - can you try with latest SDL source which has the Android_lock_running() inside ? - can you also add log/trace into this java function: onSystemUiVisibilityChange() > - does it really need the MULTISAMPLE to be set ? Without multisample app jumps only once after start and then it goes fullscreen. With multisamples it jumps every 0.5 seconds > - can you try with latest SDL source which has the Android_lock_running() inside ? I tried that, it seems to partially fix the issue: The app still jumps after the start. But when i minimize and then maximize it, it stops jumping, but there is a black line in the bottom of the screen, same height as my android status bar (which should be on the top, but invisible becuse the app fullscreen flag is true): https://i.imgur.com/Pt93hqD.jpg > - can you also add log/trace into this java function: onSystemUiVisibilityChange() It is called only once: 07-03 13:40:35.153 V/SDL (12441): pixel format RGBA_8888 07-03 13:40:35.153 V/SDL (12441): Window size: 1080x1845 07-03 13:40:35.153 V/SDL (12441): Device size: 1080x1920 07-03 13:40:35.193 V/SDL (12441): onWindowFocusChanged(): true 07-03 13:40:35.193 V/SDL (12441): nativeResume() 07-03 13:40:35.703 V/SDL (12441): nativeFocusChanged() 07-03 13:40:35.723 V/SDL (12441): COMMAND_CHANGE_WINDOW_STYLE 07-03 13:40:35.733 V/SDL (12441): SDLActivity.mFullscreenModeActive = true; 07-03 13:40:35.793 V/SDL (12441): surfaceChanged() 07-03 13:40:35.793 V/SDL (12441): pixel format RGBA_8888 07-03 13:40:35.793 V/SDL (12441): Window size: 1080x1920 07-03 13:40:35.793 V/SDL (12441): Device size: 1080x1920 07-03 13:40:35.833 V/SDL (12441): onSystemUiVisibilityChange visibility 6 The if-expression in onSystemUiVisibilityChange is false so the function does nothing After the app is minimized and maximized:
07-03 14:04:07.893 V/SDL (14258): onStart()
07-03 14:04:07.893 V/SDL (14258): onResume()
07-03 14:04:07.913 V/SDL (14258): surfaceCreated()
07-03 14:04:07.913 V/SDL (14258): surfaceChanged()
07-03 14:04:07.913 V/SDL (14258): pixel format RGBA_8888
07-03 14:04:07.923 V/SDL (14258): Window size: 1080x1845
07-03 14:04:07.923 V/SDL (14258): Device size: 1080x1920
07-03 14:04:07.983 V/SDL (14258): onWindowFocusChanged(): true
07-03 14:04:07.983 V/SDL (14258): nativeResume()
07-03 14:04:08.483 V/SDL (14258): nativeFocusChanged()
07-03 14:04:08.523 V/SDL (14258): COMMAND_CHANGE_WINDOW_STYLE
07-03 14:04:08.523 V/SDL (14258): SDLActivity.mFullscreenModeActive = true;
07-03 14:04:08.573 V/SDL (14258): surfaceChanged()
07-03 14:04:08.573 V/SDL (14258): pixel format RGBA_8888
07-03 14:04:08.573 V/SDL (14258): Window size: 1080x1920
07-03 14:04:08.573 V/SDL (14258): Device size: 1080x1920
07-03 14:04:08.593 V/SDL (14258): onSystemUiVisibilityChange visibility 6
07-03 14:04:08.593 V/SDL (14258): onSystemUiVisibilityChange visibility 0
07-03 14:04:08.593 V/SDL (14258): onSystemUiVisibilityChange handler Handler (android.view.ViewRootImpl$ViewRootHandler) {2df96b10}
07-03 14:04:10.593 V/SDL (14258): rehideSystemUi
07-03 14:04:10.613 V/SDL (14258): onSystemUiVisibilityChange visibility 6
App does not jump, but there is a black line on the bottom of the screen: https://i.imgur.com/Pt93hqD.jpg
If it doesn't jump up and down many times, then I thing this is fixed by the lock_running, and we can close the issue If it jumps once, I think this is similar to bug 4256 or bug 4300. It constantly jumps, roughly every 0.5 seconds ah yes, you said it still jumps, even with the patch. I am not sure, maybe in the kivy java side, it try also to go fullscreen .. I reproduced this, without kivy, just pure sdl c app, with code and apk i have posted above ok, sorry, I misread. I tried several device and I couldn't reproduce the issue with the apk. What happen if you comment this line in SDLActivity.java: mSingleton.sendCommand(COMMAND_CHANGE_SURFACEVIEW_FORMAT, format); also for the test-case, is it needed to have this issue: -to create another context: SDL_GL_CreateContext ? -to use the SDL_Renderer ? Moving all the remaining target-2.0.10 bugs to target-2.0.11. If these still aren't resolved when 2.0.11 ships, we should probably remove the keyword altogether. --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. (In reply to Sylvain from comment #15) > What happen if you comment this line in SDLActivity.java: > > mSingleton.sendCommand(COMMAND_CHANGE_SURFACEVIEW_FORMAT, format); > > > also for the test-case, is it needed to have this issue: > -to create another context: SDL_GL_CreateContext ? > -to use the SDL_Renderer ? someuniquename, if you get a moment, can you see if Sylvain's comment changes anything? Pretty soon we're going to have to remove the target-2.0.12 keyword from this bug (and sometime after that if we still make no progress, close this bug as WORKSFORME). Tracking down issues like this can be tedious, so we genuinely appreciate it if you can give us a little more of your time on this. Thanks, --ryan. |
