NGUI Frozen on iPhone after sleeping for a while

[TeddyDief]

Hi!
I've found that sometimes, if my iPhone app has been asleep for several hours and I open it back up, Unity picks up where it left off, but NGUI isn't receiving input. This is difficult to test specifically because it requires waiting for hours at a time between tests.

Has anyone seen this NGUI freezing on iPhone or iPad, and can advise some way to wake up NGUI's input?

Thank you!

[rain]

No exceptions in the XCode log?

[Darkmax]

i'm having this issue with my iphone when i, stop using the phone for a while and i start using again the app this happens, but in some cases the gui responds but all mess up so i need to close the application and start it all again.

I hope some know why is this happening.

[Radazen]

I'm experiencing the same issue mentioned in the original post, and it's pretty consistent and easy to reproduce. On my iPhone 4S and on my iPhone 5 (and probably on all of my iOS devices, but these are the two I've tested on), if I run my app, press the home button, and then resume it again some 10-12 hours later, NGUI freezes for a little while (anywhere from 5 to 30 seconds, in my experience) before reacting to my input again. The freeze duration seems to be proportional to the amount of time since I last used the application. So if I do it late at night, go to sleep, do other stuff in the morning, and then resume the app later that day, it freezes for a very very noticeable 20-30 seconds, but if I only wait a few hours, the freeze only lasts something like 5 seconds and isn't as apparent.

Given that the freeze duration seems proportional to the amount of time that's passed since I actually used the app, I'm guessing that it's something related to Time.realtimeSinceStartup, but I searched through the NGUI code and couldn't find any obvious place where realtimeSinceStartup would be causing the issue.

[Radazen]

Also, for context's sake: the scenes that I see this happening in include a UIDraggable panel, buttons, and input fields. None of these things react to input when the freeze is happening.

[ArenMook]

Hmm... interesting. I may have an idea.

[ArenMook]

Open up IgnoreTimeScale's UpdateRealTimeDelta() function, and add this after line 49:

1. if (mTimeDelta > 1f) mTimeDelta = 1f;

You may also need to do a search for "int ms" (4 references in NGUIMath.cs), and make sure that:

1. if (deltaTime > 1f) deltaTime = 1f;

[Radazen]

Changes made. I'll report back in a couple of days when my phones have had enough idle time to test the issue. Thanks.

[Radazen]

Well, there's good news and bad news.

The good news is that the change in IgnoreTimeScale.cs does fix the problem. There's no freezing whatsoever when I resume the app after keeping it suspended for 12-16 hours.

The bad news is that the springy momentum movement of my UIDraggablePanel is broken by the change. For a while after I resume (actually, it's pretty similar to the way the freeze worked: the longer the app was suspended, the longer this issue lasts), there's no momentum when I drag. I can drag the panel, but it stops immediately when I stop dragging it. After a little while, it'll go back to having momentum. It's a much more exaggerated effect than the freeze was, though; 5 minutes of suspending the app is enough to make this issue very apparent on resume.

My inclination is to remove the changes in NGUIMath.cs, since they're in code related to spring lerping and dampening, but those changes don't end up being necessary anyway. deltaTime is always clipped to 1.0f before the clipping code I added to those methods, so removing the clipping code in NGUIMath.cs doesn't do anything.

Do the spring panels use some sort of accumulator? What I see with debug prints is this:

==================
No changes
==================
SpringDampen: deltaTime = 0.017
SpringDampen: deltaTime = 0.018
SpringDampen: deltaTime = 0.016
SpringDampen: deltaTime = 0.017

SUSPEND, WAIT A WHILE, RESUME

SpringDampen: deltaTime = 1752.508
SpringDampen: deltaTime = 0.017
SpringDampen: deltaTime = 0.018


==================
IgnoreTimeScale.cs changes
==================
SpringDampen: deltaTime = 0.017
SpringDampen: deltaTime = 0.018
SpringDampen: deltaTime = 0.016

SUSPEND, WAIT A WHILE, RESUME

SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1

<this goes on for quite some time, and my drags have no momentum while deltaTime = 1>

SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1
SpringDampen: deltaTime = 1

<eventually, we go back to normal deltaTime values, and my drags have momentum again>

SpringDampen: deltaTime = 0.018
SpringDampen: deltaTime = 0.016

[ArenMook]

I have a feeling you put this before line 49, not after as I suggested. This is how it should be:

1. mActual -= mTimeDelta;
2. if (mTimeDelta > 1f) mTimeDelta = 1f;

[Radazen]

Ah, oops. My line numbers were off by 1 because of a debug print I put in when I was trying to diagnose the issue a few days ago. Trying the suggested change now. Thanks!

[Radazen]

Yup, that does it. No freeze on resume, no weirdness with spring dampening. I kept the changes in NGUIMath.cs, though I don't know if they're necessary or not. I'll remove those changes and see if everything still works properly.

[ArenMook]

You can keep them. You will see this change in the next update as well.

[Radazen]

Works for me. Thanks for the assistance!

[Darkmax]

thanks works great