Skip to main content
Frédéric C.
Inspiring
April 16, 2013
Question

Air 3.7: Big stuttering on GPU Retina mode after being idle

  • April 16, 2013
  • 2 replies
  • 4679 views

Hi,

I'm using GPU mode to display smooth scrolling texts vertically. I'm first rendering the text to several bitmaps, that I put in a Sprite container. Then I move the container. The results are very smooth, and work fine.

But due to the upcoming constraint of publishing all new Apple apps with Retina support (from 1st of May), I began to test it by adding the following tag to my XML:

<requestedDisplayResolution>high</requestedDisplayResolution>

Actually it was very straightforward, as all my assets are already in retina resolution (640x960). The scrolling was still smooth, so I was quite happy. Until I found a very annoying bug: if I leave the app idle, and my iPod 4G goes to sleep, when I wake it up, the app becomes VERY jerky. Even if I go to various sections of the app, calling for System.gc(), I can never get a smooth response again. I have to quit the app and launch it again. I rebooted my iPod, but the issue still occurs.

If I don't activate the <requestedDisplayResolution> tag in my XML, this problem is not there (a few hiccups, but nothing compared to the lag I get with Retina resolution). What's strange is that memory-wise, it is exactly the same, since in non-retina mode, I still use Retina assets that are scaled-down by Air automatically. So maybe there is a fill-rate issue, but that only happens after waking up from idle mode, so I know the device can handle it. FYI, I set StageQuality to LOW.

I even tried to keep the app awake using the systemIdleMode feature, but I keep getting inconsistent crashes when I press the Home button, then coming back to the app.

Did someone already encounter this issue? It could be a real showstopper for all GPU mode users once Retina support becomes mandatory.

Thank you very much for your help!

Frédéric

This topic has been closed for replies.

2 replies

Inspiring
September 11, 2013

Hi Frédéric,

This is an important issue that affects a lot of users.  Thank you for opening the bug report.  I've spread the word, and asked people to vote and comment on this.

I've seen it occur after sleep and wake-up, but more commonly after orientation change.

On your bug report, Adobe requested source code to allow them to reproduce the issue.  Did you send this?

I have a program that exhibits this behaviour, but not a neat and small test sample.  I can look into making one if you don't have anything -  Let me know.   I'd like to push for this issue to be resolved in AIR 3.9.

Frédéric C.
Inspiring
September 11, 2013

Hi Daniel,

Thank you for spreading the word. It's been a while, and I don't think I provided extra source code. So if you have some code that illustrates the problem, please feel free to send it to Adobe, it will be appreciated.

Thank you very much!

Frédéric

Inspiring
September 25, 2014

Well, it may be related, yes. But in my case, I have a few big bitmaps in a sprite, one below the other (I render some text into bitmaps to create a smooth scrolling text). I made a text scrolling class that reproduces the standard iOS scroll movements (with bouncing effect at the end of the scroll). Nothing really complicated.

But when I go to sleep mode, and come back, then the scrolling is sometimes very jerky EVEN if I fully scroll text in both ways (which should normally reload all the bitmaps to the GPU if they were unloaded). From now on, the scroll will remain jerky until I close the app completely, even if I scroll in all directions a few times, like if AIR had lost some kind of vsync with the screen. I know AIR GPU mode doesn't really use vsync, but you'll get the idea.

So I don't know if the Stats gadget keeps AIR refresh system "alive", preventing this desynchronization problem. Maybe in GPU mode, if the screen is totally idle, AIR deactivates screen refresh to save battery and that doesn't get reactivated correctly once the user gets back to the app? Some recent info in AIR 3.9 release notes is also interesting:

"Stage3D based apps are not able to execute background tasks like audio playback, location updates, network upload/download etc. iOS does not allow OpenGLES/rendering calls in the background.

Applications which attempt to make OpenGL calls in the background are terminated by the iOS."

Since GPU mode could also probably rely on OpenGLES, the issue may occur when AIR reactivates some rendering process? Well, I'm only speculating here, as only Adobe could tell...


Hey Frederic, can you share the scrolling class for iOS?  I would like to add the ability to add scrol instances to scroll sprites or MC's. 

Cheers

Adobe Employee
April 17, 2013

Hi,

Thank you for your bug report. Could you please open a new bug at bugbase.adobe.com, please include all information needed like OS version, SDK used, sample application. This would help us to investigate the problem. Once added, please post back with the bug URL so that others affected can add their comments and votes.

Regards,

Nimit

Frédéric C.
Inspiring
April 17, 2013

Hi,

I opened a bug report here: https://bugbase.adobe.com/index.cfm?event=bug&id=3543703

I hope a solution will be found. Thank you!

Inspiring
April 19, 2013

I have been struggling with this issue in my AIR apps for 2 years now. I stumbled across a strange fix by accident.

I implemented a simple monitoring script to check for some memory leaks.  For some reason this tool when running eliminates this strange problem. At first I thought it was because this tool obviously has some sort of running process thats constantly measuring available memory, etc. This isnt the case though. I've tried many other memory monitoring tools and they dont fix the issue.

Download this .as file

http://mrdoob.googlecode.com/svn/trunk/libs/net/hires/debug/Stats.as

import net.hires.debug.Stats;

addChildAt( new Stats(),0 );   // Add to the background so it isn't visible.

I can confirm that adding this in the background does not give a performance hit to your app.