Android application switch does not call DeviceReset event

[emiswelt]

Hello,

We are using Monogame and Xamarin to develop an application on android. For testing, we use a Google Nexus 4.

To reload some textures which are created at runtime, we subscribed to the GraphicsDeviceManager.DeviceReset event.

However, when an app switch happens (the home button is pressed to exit the application, then, the app is resumed), the event is not fired.

Furthermore, Monogame’s content manager fails to re-load resources, like textures and sprite fonts.

What could we be doing wrong here?

best,
Emanuel

[daveleaver]

I pushed up a fix for the reloading of textures yesterday, see issue #2443

If you need to regenerate your own content when this happens, you need to implement the IResumeManager interface and do something like this:

((AndroidGameWindow)myGame.Window).SetResumer(myResumer)

I haven’t done this myself, but it should be the way.
If you have any issues, please post as I might have broken this when tidying up AndroidGameWindow

[daveleaver]

Any hopefully I can post links now:

The Fix

Fix android texture death on resume

And IResumeManager.
https://github.com/mono/MonoGame/blob/develop/MonoGame.Framework/Android/IResumeManager.cs
Check the comments, they describe the usage

[Aranda]

@daveleaver

If you need to regenerate your own content when this happens, you need to implement the IResumeManager interface and do something like this:

IResumeManager and the default ResumeManager implementation are there to help alleviate the long wait while MonoGame reloads all graphics content. It’s intended for drawing a resuming/loading animation of some kind.

The DeviceReset event is the right place to recreate procedural graphics content. If it’s not being called when the app is resumed and the GL context is lost (as the black textures would indicate), then something is definitely wrong.

[daveleaver]

Sorry, @Aranda is correct!
Thanks, I didn’t know that

[emiswelt]

The DeviceReset event is the right place to recreate
procedural graphics content. If it’s not being called when the app is
resumed and the GL context is lost (as the black textures would
indicate), then something is definitely wrong.

Uhm.
Do you think something is wrong with our application (it’s running fine on Windows Phone)?
Or could it be a bug in MonoGame?

Thanks for the help in any case, Aranda and daveleaver!

[Aranda]

It sounds to me like the problem is with MonoGame. In fact I’d be willing to bet it was due to Dave’s recent change here: https://github.com/mono/MonoGame/commit/50638fcb28181beb38957f41b3b07764de61b5bb. I recall adding the _contextWasLost variable was required to detect that the GL Context needed to be recreated and hence textures needed to be reloaded.

[KakCAT]

Hi Aranda,

I’m probably the cause of the problem. When describing the issue #2427 I said that I thought that the _contextWasLost variable was not being set correctly. Dave submitted the PR and he thought that I knew what I was talking about

However that was true for my device (Galaxy Tab 3 10.1"), _contextWasLost was not being set when I was pausing/resuming my game, despite the textures were obviously lost (black rectangles).

[KakCAT]

Hi!

I just tested my game with the aforementioned Galaxy Tab and a Nokia X, and in both devices the DeviceReset is being called and textures restored. Other than taking eons to restore in the Nokia X I see no problem on those two devices.

Are you sure Emiswelt that you’re using the MonoGame version with Dave’s #2443 patch?

[Aranda]

@KakCAT

for my device (Galaxy Tab 3 10.1"), _contextWasLost was not being set when I was pausing/resuming my game, despite the textures were obviously lost (black rectangles).

@KakCAT

Galaxy Tab and a Nokia X, and in both devices the DeviceReset is being called and textures restored

Ok that’s interesting, perhaps the old logic for setting _contextWasLost did not work for all devices and the new logic does not work for the device @emiswelt is using.

[KakCAT]

Hi Aranda,

it could be possible. However in the old code DeviceReset wasn’t being reseted in most devices because CreateFrameBuffer was not being called even after app pause/resume event (that was the original problem which caused the modification)

That’s why I asked @emiswelt about the version he’s using, that would make clear wether _contextWasLost is the problem or not (it could be just than he didn’t update and he’s having the problem some of us have had too).

actually, if I’m not wrong, the absence of _contextWasLost should mean that the context was being restored when it shouldn’t (losing precious time) rather than not being restored, isn’t it?

Thanks
Kak

[Aranda]

Hi KakCAT,

Very true, it could well be that @emiswelt is not on the latest Github and the issue is indeed fixed already. Hopefully that’s the case.

@KakCAT

actually, if I’m not wrong, the absence of _contextWasLost should mean that the context was being restored when it shouldn’t (losing precious time) rather than not being restored, isn’t it?

That’s a good point. It might be that SurfaceCreated is actually called each time the app is resumed even when the context is not lost.

[Aranda]

Although we’ve not heard back from @emiswelt, another person has confirmed that the recent fix by @daveleaver also fixes the texture reload issue they were having: Android onResume doesn't seem to resume content

@Aranda

In fact I’d be willing to bet it was due to Dave’s recent change here:…

I’m now officially eating my words. Seems Dave’s change fixed the problem rather than introduced it

[daveleaver]

haha, that’s alright
This is a tricky area of Andriod. Luckily I had randomly stumbled across a blog post that talked about the same issue.

[Ian_Weeks]

Hi @Aranda, @daveleaver - not sure if this is related or not, but whenever I switch between my game and another app, then switch back, it takes a very long time for the screen to reappear. Looking through the log, it seems that the graphics context is being trashed and then it is having to recreate all the graphics internally automatically again when the app is resumed - causing the massive lag.

Why is it doing this? Is reloading of the all the graphics really necessary? Other games manage to switch instantly between themselves (and the Home screen) and back again with no noticeable lag - why is it with Monogame?

Note that if I lock/unlock the device, the game returns instantly.

Also note that all of the textures are restored, so that isn’t the issue - just the massive pause when the app is resumed after being backgrounded.

Can a fix be applied to stop it from trashing the context if its unnecessary? Is there another workaround to reloading the textures?

Many thanks!

[daveleaver]

This will probably do it once implemented https://github.com/mono/MonoGame/issues/2600

[Ian_Weeks]

Great! DeanEllis over on the Xamarin forum (http://forums.xamarin.com/discussion/621/androidgameview-pause-without-losing-gl-context/p2) mentioned the patch for AndroidGameView and a similar fix to Monogame was required - any idea when this is likely to happen?

I’m waiting on releasing an Android game and I can’t do that until this issue is resolved - pausing/resuming and having massive lag times inbetween just makes the product look totally amateurish.

Thanks, Ian.

[daveleaver]

There is a PR up here that should implement fast app resume:

Android fast app resume

Please give it a test and post your results on there