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

Report · Apr 16, 2013

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:

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

Report · Apr 16, 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

Report · Apr 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!

Report · Apr 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.

Report · Apr 19, 2013

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

Wow! I just figured this out myself, not two hours ago! (I wasn't sure until I saw this post just now).

Similar problem: I have two Retina-sized jpegs as background for an iPad app. Every once in a while, the app will "hang" on orientationChange and take about a half second to update the screen. (@ OP, it's an intermittent issue here, and usually is fine when waking from sleep, though. Note, however, I also don't have much to scroll or animation going on, either, so I can't say for sure if it's the exact same issue you're experiencing)

I've been trying all sorts of things all afternoon to figure this "orientation stutter" from various methods of adding/hiding the landscape gfx (or portrait, depending) to seeing if the non-visible mc was getting garbage collected. No dice. However, I DID notice that I was NOT able to reproduce the issue whenever I had the Mr. Dood monitor running! Soon as I took it out... bam! Problem comes back! I brushed it off as coincidence, but now I will have to look at that closer!

Thanks for chiming in, Applauz78, I will consider your workaround.

(Testing on iPad 3 and iPad mini)

update: Just realized I am still on AIR 3.6, wheras OP is talking 3.7. On 3.6 I do not have the "wake from sleep" issue. Only the occassional orientation stutter described above. (Just tested Retina/GPU performance on my iPhone 4S as well)

Report · Apr 21, 2013

Thank you very much Applauz78!

I did some tests, and indeed it seems to help! Maybe the fact there are constant updates on the screen keep the display system alive... I'll try to identify what really creates this positive effect, but it requires time, since I have to make a full adhoc compilation to test for changes.

Anyway, thank you very much for your help!

Report · Apr 21, 2013

Yes, I did some additional tests and find the monitor class does indeed help!

Some additional notes:

-- setting the Stats.visible to false will not help prevent screen stutter

-- placing the Stats off-stage will not help prevent screen stutter

As Applauz78 reports, you need to place the Stats under an object on screen to hide it's appearance and receive the benefits of whatever's going on to keep the screenplay smooth.

Yes, Frédéric, it would be nice to find out what is going on to make this work. (can't believe how much dev time goes into bending Flash to meet basic iOS functionality...!)

Report · Sep 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.

Report · Sep 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

Report · Sep 11, 2013

Are you guys sure this isn't caused by the fact that the bitmaps unload and do not stay in memory when no animation is happening on screen?

It could explain why the Stats class seems to help, because it is constantly animating on top of the content.

Report · Sep 11, 2013

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...

Report · Sep 11, 2013

I speculated it might be related to a GPU texture upload bottleneck. On Android Stage3D/(OpenGLES) loses context on screen orientation change. But iOS shouldn't - so I'm not sure what's going on, or why keeping the screen "alive" helps.

I tried writing a small example to demostrate this. I haven't managed yet. Although I CAN reproduce it with a REAL application - but that's not very convenient to demonstrate the bug to Adobe. (It's a sophisticated app, with a user account, and complex steps to reproduce the problem.)

Can anyone help? Below is my code following Frédéric's description from the bug report. But it doesn't cause any noticable stuttering? Is this what you meant Frédéric?

package com.powerflasher.SampleApp {

import flash.display.DisplayObject;

import flash.geom.Point;

import flash.events.MouseEvent;

import flash.display.StageQuality;

import flash.display.Sprite;

import flash.display.StageAlign;

import flash.display.StageScaleMode;

public class TestU extends Sprite {

protected static const ROWS:int = 20;

protected static const SIZE:Number = 1024.0;

[Embed(source="images/image.jpg")]

protected static const IMAGE:Class;

protected var _movingLayer:Sprite;

protected var _startY:Number;

public function TestU(screen:Sprite = null) {

if (screen)

screen.addChild(this);

stage.align = StageAlign.TOP_LEFT;

stage.scaleMode = StageScaleMode.NO_SCALE;

stage.quality = StageQuality.LOW;

makeMovingLayer();

addEventListener(MouseEvent.MOUSE_DOWN, mouseDown);

}

protected function mouseDown(event:MouseEvent😞void {

_startY = mouseY;

stage.addEventListener(MouseEvent.MOUSE_MOVE, mouseMove);

stage.addEventListener(MouseEvent.MOUSE_UP, mouseUp);

}

protected function mouseMove(event:MouseEvent😞void {

_movingLayer.y += mouseY - _startY;

_startY = mouseY;

}

protected function mouseUp(event:MouseEvent😞void {

stage.removeEventListener(MouseEvent.MOUSE_MOVE, mouseMove);

stage.removeEventListener(MouseEvent.MOUSE_UP, mouseUp);

}

protected function makeMovingLayer():void {

addChild(_movingLayer = new Sprite());

for (var rows:int = 0; rows < ROWS; rows++) {

var image:DisplayObject = new IMAGE();

_movingLayer.addChild(image);

image.y = rows * SIZE;

}

Report · Sep 18, 2013

Hi Daniel,

Thank you for your example. Yes, it's a good illustration. Upon request, I just sent a sample to Adobe (sorry, I'd like to keep some of the code private for now, so I can't post it here), but I hope it will help them reproduce this behaviour. Unfortunately it's rather erratic, so it's difficult to create something that has the same issues without sending a complete complex project.

Report · Sep 25, 2014

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

Report · Sep 19, 2013

@Bram001 - can you point me to info on the bitmap thing. I have an app for images and notice after idle, there is a studder in the first response or user input and sounds like what you describe. Would a simple animation of a transparent movieclip keep the bitmaps in memory?

Report · Apr 19, 2014

Did anyone solve this?