A little probleme with Air 2.7 in GPU?

[Yacine__Dooprod_]

Hi!

Like everyone here, I saw that Air 2.7 is now out, very exciting stuff!

So to test that, I just take an old .fla (a game) who work very well with Air 2.6. I copy-past the .swf / . xml / .provision / .p12, and when I export...

It's like the game is in high resolution (the image is in 960x480). So I thought maybe I have something wrong in my file, maybe in the .xml I forgot the "high" instead of "standard"... I check everything, nothing wrong... I try to change the display mode in CPU and surprise, it's working! Fullscreen mode / Standard display it's cool. I change for GPU mode and again, the screen is in high resolution and reduce by half my app!

Does anyone else have this weird bug? Or maybe in GPU it's in High Resoution by default?
CPU mode is cool by the way, but I NEED GPU (my game is built around that for better performance).

Thanks!

[Mike0431]

Hi jonas,

Your interval class works great.

I have yet only used it at the start of my app where the timer bug was making it crash

so I don't know if it makes air 2.7 more efficient than 2.6.

I have a lot of timers in my app.

It doesn't sound good that you're still getting a better gpu performance out of 2.6.

[Guest]

@Mike0431

Hello,

"So I don't know if it makes air 2.7 more efficient than 2.6."
-> Yes for my application.
My problems comes from modifications made to identify my Timeout problem... ( sound played three times instead of one)

"I have a lot of timers in my app."

-> I think it should work well .
Interested by feedback if you test.
Even with my sound problem, I had an obvious improvement on my application at 60 fps...

[Mike0431]

Hi Sanika,

This is the bug id for the gpu performance issue.

2904026. https://bugbase.adobe.com/index.cfm?event=bug&id=2904026

[Guest]

Here is a test file for theTimer bug

https://github.com/jonasmonnier/Mobilo/blob/master/src/test/AdobeTimerTest.as

[Colin Holgate]

What devices do you find show a problem with that routine? I had a one time glitch with my iPhone 4, where the first timer came in late, but aside from that all subsequent timings came in ok, and subsequent launches had a good timer first go too. My iPad was good from the beginning.

There is about a third of a second added each loop, which I explained is down to how the handling of the event extends the loop's time. In this case I would guess that most of the third of the second was in updating the textfield, which is a slow operation in Flash apps.

I just tried my 3GS too, it matched the other two, even on its first launch. And I tried my Android tablet, it actually had less delay each loop, managing to update the textfield a lot faster than the iOS devices.

[Guest]

Hello,

Tested on my 3GS, OS4

Compiled with AIR 2.7, renderMode GPU, fullscreen.

Test class here :

https://github.com/jonasmonnier/Mobilo/blob/master/src/test/BigIntervalTest.as

Added my Interval class to compare.
I first run the Timer() and then the Interval.create().
The time between two calls is respected but with 15 sec lag...

I have a "similar" problem with setTimeout() -> http://forums.adobe.com/thread/866423?tstart=60

I miss something?

[Colin Holgate]

It's fairly common that apps run a bit slower the first time they are used. Not sure if it's that some unpacking is going on. In any case, notice how all of your timings are exactly 20 seconds apart, other than the first one being late? Did the first one come in on time the second time you rant the app?

[Guest]

@Colin Holgate

It's fairly common that apps run a bit slower the first time they are used.

-> Yes but 15 sec is not "a bit slower"
-> Yes but it works correctly with AIR 2.6

-> Yes but my workaround works well

In any case, notice how all of your timings are exactly 20 seconds apart, other than the first one being late?

-> For me they are all late

Did the first one come in on time the second time you rant the app?

-> I do a lot of testing and bug occurs every time. All events are dispatched sometimes too early, sometimes too late

[boat5]

funny, glancing over this thread i thought it was an iOS issue only. I am using a droidX w/ android OS 2.3 (gingerbread) w/ gpu and fullscreen Air2.7 and was not seeing the issue... then it came up, I have only seen it happen twice now but i simply cannot reproduce it at will.

anyway thanks colin for pointing out the work around for now!

[Colin Holgate]

Would be interesting to hear if you find it fixes things on Android too.

[boat5]

I havn't tried yet but when i do ill let you know, again i can't seem to reproduce it and i only saw it twice, so it will take a bit before i can assume its stopped happening.

[jpeitz]

Content deleted.

How do I delete a post in this forum?

[sanika_Kulshreshtha]

Hi Mike,

Thanks for reporting the bug. Could you attach a sample application which can demonstrate the bug? Since the performance dip that you are seeing is because of the timer bug, it should be reproducible in cpu mode too. We believe that there should be no or negligible performance change between AIR 2.6 and AIR 2.7 if the stageQuality is not set to HIGH. Till 2.6, it was capped to medium and in 2.7, stageQualty = high is honoured. It would make sense to compare performance by setting stageQuality to medium.

Thanks again for the help.

Regards,

Sanika

[Mike0431]

Hi Sanika,

I added a note on bugbase.

The timer bug also happens when compiling in cpu render mode
using air 2.7.It is not only gpu.

I have tested stageQuality HIGH, LOW and MEDIUM.

Timer bug test:

source code for test https://github.com/jonasmonnier/Mobilo/blob/master/src/test/AdobeTimerTest.as by Jonas Monnier.

timer delay set to 20 seconds.

test device: ipad 2 os4.

fullscreen is set to true for all except for air 2.7 gpu which has a fullscreen bug.

My results:

air 2.6 gpu - 20329, 40653, 60978, 81308   working as it should.

air 2.7 gpu - 33633, 53633, 73633, 93633

air 2.7 gpu test 2 - 37709, 57709, 77709, 11709

air 2.7 cpu - 38138, 58138, 78138, 98138

When compiled in air 2.7 the timers initial call is wrong.

[sanika_Kulshreshtha]

Hi Mike,

Thanks a lot for testing it. Appreciate it!

Regards,

Sanika

[Mike0431]

Hi Sanika,

You mention that there should be no or negligible performance change between air 2.6 and 2.7.

I thought air 2.7 was going to improve gpu as well as cpu? http://sonnati.files.wordpress.com/2011/04/senza-nome.jpg

[sanika_Kulshreshtha]

Hi Mike,

With CPU mode, you should see significant improvements in AIR 2.7. With GPU mode, we don't expect the performance to degrade, it should be comparable with GPU mode in AIR 2.6.

Sorry for not being clear earlier.

Thanks,

Sanika

[Mike0431]

The timer bug has been fixed.

How can I test the air sdk.

[Guest]

Still having this issue and not seeing a real solution here. What can I do? We still don't even have an official implementation of Air 2.7 in CS5.5 as far as I know.

[Trevor-twenty5eight]

Don't know if this will help anyone or if you have a different issue but I just found a thread about the white screen problem being caused by MCs larger than 1024 x 1024 px...

Sorted my issue right out. Hope it helps someone else.

http://help.adobe.com/en_US/as3/mobile/WS901d38e593cd1bac-3d719af412b2 b394529-8000.html

[Elliot_Mebane]

The AIR SDK was recently updated and the Fullscreen/GPU problem has reportedly been fixed. The SDK download page hasn't been updated, but it is a new payload.

http://www.adobe.com/products/air/sdk/

[boat5]

It was mentioned here that the fix was specific to iOS:

http://forums.adobe.com/message/3808925#3808925

I downloaded the SDK about 4 days ago, unless its changed since then (no date on the download link) I can confirm its corrected on my iPod4, but not android.

[AsterLUXman]

I believe that Air 2.7 on the GPU is unstable, particularly and possibly exclusively on iPad1.

I am seeing 2 types of crashes:

Crash type #1:  GPU memory overfill issue on iPad1

• I have had several apps crash on iPad1 when using the GPU in Air 2.7 and Air 2.6.  These apps tend to have a lot of assets that are rendered as bitmaps (either via CAB, or by drawing shapes to bitmaps manually).  The crashes tend to happen when these assets are rendered.
  

• CPU versions work fine, though, but are not always desired due to pixelated look on iPad, and the fps can be diminished too.

• My guess is that the GPU memory can fill up faster than the garbage collector can get to it.  When the GPU memory is full: the app will simply exit (crash), even though there is a substancial garbage collection debt, which if it had cleared, would have kept GPU memory below capacity (avoiding the crash).

• This problem seems specific to iPad1, as I haven't seen it occur on iPod Touch 4th Gen.

Crash type #2: Switching between an Air 2.7 CPU app and GPU app on iPad1

• This issue is specific to Air 2.7 GPU (Air 2.6 GPU is ok).
  

• Switching between an Air 2.7 CPU app and another Air 2.7 GPU app can cause the device to freeze completely.  The iPad shows a blank screen, and the iPad buttons are unresponsive (!), in other words: a complete lock up.

• Switching between an Air 2.7 CPU app and an Air 2.6 GPU doesn't cause the device lock up.

• I have seen this behavior happen between different sets of apps, but always the problem was when switching to a GPU Air 2.7 after running a different CPU Air 2.7 app
  

My advice to developers:

• If you are going to make a GPU app, use Air 2.6 (not 2.7)

• If you want to make a CPU app, it will of course run faster in Air 2.7

• If you want to make an iPad version of an app, you'll have an easier time cerating a different SKU altogether (do not select "iPhone + iPad" in CS5.5).  Also, once published as an iPhone + iPad app, you won't be able to remove the iPad version from the app store, if something is wrong with the iPad version.
  

• If you do a tablet version: try it on an iPad1, it's the least common denominator (less GPU mem than an iPad2, and slower GPU too).

[AsterLUXman]

Addendum - Tips on increasing scrolling smoothness on iPad1:

Using Air 2.7/CPU mode:

1. In the init function, when the program starts, set stage.quality = StageQuality.MEDIUM.  Note: I have seen rendering issues (video memory corruption), when using HIGH or BEST, on iPhone4 in CPU mode, with the resolution in CS5.5 set to "High" (retina display).  Medium works fine.
   
2. Render all your textures and static vector assets (except TextFields) to bitmaps manually, baking in all the filters you need, such that the bitmapDatas generated are 2-4 times the size they will appear on the screen, BUT their containers (Bitmaps) are inversely smaller (scaleX/Y are set to 1/2-1/4)
   
3. For TextFields, set cacheAsBitmap = true and antiAliasType = AntiAliasType.ADVANCED
4. At the end of initialization, set stage.quality = StageQuality.LOW

What we did:

Setting StageQuality.LOW increases the scrolling speed tremendously, but bitmaps are no longer bilinearly sampled.  To prevent downsampling artifacts in nearest-neighboor mode, we have to render our bitmaps at 2x their final screen resolution. Edges will still appear aliased, but they will be continuous looking (no "pits").  For textfields, setting antiAliasType to ADVANCED took care of the aliasing, even if the stage quality eneded up being LOW (actually the aliasing quality of text gets pulled down slightly, but it's still quite good).

Using this method, I was able to improve the smoothness of scrolling of big blocks of text + vector shapes.  As a bonus, it will also improve scrolling speed on retina displays, if you set CS5.5 rendering quality to "high".

Choosing the right upscaling factor: 2x or 4x ?

The amount of upscaling you need to do (2x or 4x) depends on your  fla's starting resolution.  If you start with a 320x480 file in CS5.5,  and select "iPhone + iPad", you need to detect at runtime if this is an iPad, or an iPhone.  I use the following code:

private const iPAD:Boolean = Boolean(CONFIG::IOS) ? ( (Capabilities.screenDPI % 132) == 0) : false; // modulus op to account for forthcoming iPad3

private const UPSCALE_FAC:Number = Boolean(CONFIG::IOS) ? ( iPAD ? 4 : 2 ) : 1;

Regarding upscaling:

In CPU mode on iOS (NOT on Android), if you opt to use stage.quality = StageQuality.MEDIUM (which is the default, I think), you normally get bilinear sampling on bitmaps and aliased vectors (vector edges are ugly).  Baking your vectors to upscaled bitmapDatas, gives you the benefit of bilinear sampling, thus anti-aliasing your 'vectors' on iOS.

In CPU mode on Android with StageQuality.MEDIUM, it seems however that the opposite is true:  vectors are anti-alised, but bitmaps are not bi-linearly sampled.

[luca_mezzalira]

I solved my issue on Android 2.7 with those configs:

GPU + Fullscreen + Landscape mode

I set stage quality to MEDIUM in the constructor of my document class and then when I need to renderize objectes I set it to HIGH and everything work fine for me.