Partially disappear of text fields after restore game from background on Android

[Mintonist]

I have no ideas about it:

I use ttf font:
[Embed(source="../fonts/Exo2Bold.ttf", embedAsCFF="false", fontFamily="Exo 2 Bold")]
private static const ExoBold:Class;

	private function activateHandler( event:flash.events.Event ):void
	{
//			if(mStarling && mStarling.context)
//			{
//				mStarling.context.clear();
//				mStarling.context.present();
//			}
			mStarling.start();
	}

	private function deactivateHandler( event:flash.events.Event ):void
	{
		mStarling.stop(true);
	}

Can you explain my mistake?

[PrimaryFeather]

Hey there!

Hm ... this seems similar to #1012 — which ought to have been fixed with AIR 29. Which AIR version are you using?

[Mintonist]

AIR31

I have no "cropped" textures. But some TextFields are disappeared without any errors. It is hapens only after restore game on Android. Seems it is rendering problems. I use standart AssetManager and latest Starling 2.3

[PrimaryFeather]

Hm, that's really weird. Since it happens when the game is restored from background, you're probably seeing a context restore – and TextFields normally restore themselves automatically after a context loss.

Here are a few questions that might help us get to the root of the issue:

• If it happens in a certain scene, does this always affect the same TextFields, or does it seem to be random?
• Do you have any filters assigned to the affected TextFields?
• When you call "Starling.context.dispose()" manually, is the outcome the same?
• Are you using the latest stable AIR version? (32)
• As for Starling: please try the very latest development version (head revision in the master branch).
• Finally: which languages will your game support? Maybe distance field fonts could be an alternative? (As a final option.)

[Mintonist]

If it happens in a certain scene, does this always affect the same TextFields, or does it seem to be random?

I think it is random on different scenes.

Do you have any filters assigned to the affected TextFields?

no

When you call "Starling.context.dispose()" manually, is the outcome the same?

What is the right moment for this call?

Are you using the latest stable AIR version? (32)

Yes I have plan to upgrade to AIR32

As for Starling: please try the very latest development version (head revision in the master branch).

Ok, i try it. But I want notice, that I saw this bug early with other AIR and Starling versions.

Finally: which languages will your game support? Maybe distance field fonts could be an alternative? (As a final option.)

EN/RU/DE
Ok, I read about it.

Sometimes some images (from atlases) may disapear too, but always whole images (without crop). I is like disappear few layers on display list hierarchy. Other images from same atlas present on scene.
Or it can be like on this video - https://www.dropbox.com/s/mmxkrrpk8ea3pl6/S80425-14082002.mp4?dl=0.
But I dont know is it the same problem with TextFields or not. Seems these are 3 different problems - but all after restore from background.

[PrimaryFeather]

Thanks for the additional information!

Hm, the problem in the video does look severe — and that's either a different problem, or it was simply a coincidence that we saw the original problem only on TextFields.

What is the right moment for this call?

Anytime, really. Just let the game dispose the context e.g. when you hit a specific button, and then check out if this has the same effect.

Otherwise, the first thing to do would be to upgrade to the latest AIR and Starling versions. If the problem persists, we'll dig deeper.

Fingers crossed!

[Mintonist]

The same problems with latest AIR and Starling... But!
I noticed different size of classes.dex (inside apk) while I package project on my two diferent PC. And second .apk seems have not such problems (i am not shure, because it is hard to catch it). How can it be?
Same AIR, same IDE, same code.

[PrimaryFeather]

Hm, that's an interesting find, yes — one would expect those files to have the same size. But TBH I don't know the internals of how this file is generated; it could also be a red herring.

Could you try if handling a context loss works correctly? (Via the context.dispose() call I talked about.)

[Mintonist]

context.dispose() works correctly with any build

[PrimaryFeather]

I don't suppose you have any new findings as to when the issue pops up?

Here's one thing I just thought of - it might be totally unrelated, but it's a quick test, so we should check it out. There is one rare bug in Starling's render cache that I've seen reported a few times, but could never reproduce (and thus: fix). To rule that out, we should try if the problem still happens when you completely deactivate the render cache.

To disable the render cache, override the "render" method in your game's root class (the one you're passing to the Starling constructor) like this:

override public function render(painter:Painter):void
{
    painter.excludeFromCache(this);
    painter.cacheEnabled = false;

    super.render(painter);

    painter.cacheEnabled = true;
}

It's worth a try!