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

In side-by-side mode (Android ~7+) losing focus will cause SDL_WINDOWEVENT_MINIMIZED + SDL_APP_WILLENTERBACKGROUND #3227

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2019-04-06 23:59:37 +0000, Ellie wrote:

In side-by-side mode (Android ~7+) losing focus (by tapping onto the 2nd open app so that it gets input) will cause SDL_WINDOWEVENT_MINIMIZED + SDL_APP_WILLENTERBACKGROUND even though the app is still on the screen.

This has two consequences that are a bit annoying:

  1. redrawing is no longer possible while in side by side when not focused. Other apps redraw just fine without focus, so that seems to me like that should work

  2. an SDL2 app will think it's in the background and possibly even terminate itself (like, if it's an app that terminates itself in background if nothing left to do, not an entirely impossible behavior) despite still being open & on screen, because this state can't be told apart from ACTUALLY going into background

The expected behavior would be to just get SDL_WINDOWEVENT_FOCUS_LOST and possibly SDL_WINDOWEVENT_LEAVE instead, and no events like minimization, the window being hidden, or the app going into background, or anything like that.

PS: Android 10's dev preview seems to have an experimental desktop mode with freely movable windows. I would assume that to get an SDL2 app working right in that environment, this bug might also need to be fixed

On 2019-04-07 07:37:11 +0000, Sylvain wrote:

Indeed, when you split the screen. it goes in the states pause/resume.
And we block the loop there. Maybe the app could still run though.
( This might solve bug 4580 as well ? ).

and we would really block in stop/restart

On 2019-04-07 07:39:36 +0000, Sylvain wrote:

The only thing is :
https://developer.android.com/reference/android/opengl/GLSurfaceView

Activity Life-cycle
A GLSurfaceView must be notified when to pause and resume rendering.
GLSurfaceView clients are required to call onPause() when the activity stops and onResume() when the activity starts.
These calls allow GLSurfaceView to pause and resume the rendering thread,
and also allow GLSurfaceView to release and recreate the OpenGL display.

Rndering seems to stop on pause/resume not stop/restart, but I'll try to see if that work.

On 2019-04-10 02:02:07 +0000, Ellie wrote:

For what it's worth I got curious and read the docs, and I find them to be quite contradictory so I filed an issue: https://issuetracker.google.com/issues/130114129

So far nobody seems to have cared though, but maybe some day there'll come something of it

On 2019-04-17 03:06:49 +0000, Sam Lantinga wrote:

Does the patch in bug 4580 help with this bug?

On 2019-05-09 19:18:33 +0000, wrote:

I just tried source snapshot SDL-2.0.9-12723 on android 7 droid turbo 2
I think this phone is out of date so its tough to say if it represents how split screen works on newer phones, but I did previously work around split screen issues by manually disabling the feature for my app... would love to support split screen and drag-drop features though so the user can select images that way.

Split screen is triggered by holding down the running apps menu button. I would have never found this bugs out my app except by accident.

Previously I had manually disabled split screen on my app, I think to avoid this exact issue (app fails to render once entering spit screen once). This is how I disabled it:

androidMainifest.xml

<activity ...
android:resizeableActivity="false"
android:supportsPictureInPicture="false"
>

Suffice to say I don't see split screen starting to work after this test (which turns out doesn't have all the patches from bug 4580). When I toggle those to be true it seems to revert to the same broken behavior as before.

It does look like the patches use isInMultiWindowMode which makes it seem like the app would use normal pause resume behavior until entering that mode. If thats the case then maybe those will fix this issue too.

I have a nice script now to install a new version for testing so I can try it out pretty easily.

On 2019-05-09 19:33:58 +0000, wrote:

I posted too soon... I had to merge some more things into my androidMainifest.xml and it actually sort of started working in split screen mode and SDL-2.0.9-12723 - still need to test more, doesn't seem broken though.

android:alwaysRetainTaskState="true"
android:configChanges="orientation|uiMode|screenLayout|screenSize|smallestScreenSize|keyboard|keyboardHidden|navigation"

Its easy to miss things like this when upgrading! I can't really test the new patches either except to make sure they work on my device.

On 2019-05-10 20:20:18 +0000, wrote:

I can confirm split screen which was not working on my device at in 2.0.8 or 2.0.9 is now working reasonably great in SDL-2.0.9-12723. I was able to remove the extra attributes I had added in androidMainifest.xml and split screen continues to work well (as long as I have all the default attributes).

I also observe the SDL_WINDOWEVENT_FOCUS_LOST and SDL_WINDOWEVENT_FOCUS_GAINED events.

On 2019-05-18 10:54:56 +0000, Ellie wrote:

I didn't get around to test it for a while but recently I did and completely forgot to comment, I can confirm that with hg tip it works nicely for me as well! (I tested on Android 8.1) The app continues redrawing and responds nicely to hardware mouse wheels while out of focus in side by side, it works perfectly as far as I can tell

On 2019-05-18 17:28:51 +0000, Ryan C. Gordon wrote:

This appears to be fixed; please reopen if I'm wrong!

--ryan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant