Inspiring

Question

A little probleme with Air 2.7 in GPU?

Forum|Forum|15 years ago
June 15, 2011
14 replies
13244 views

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!

Development

This topic has been closed for replies.

L

luca mezzalira

Participating Frequently

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.

A

AsterLUXman

Inspiring

It depends on your situtation.

In one of my apps, I had weird rendering artifacts when using StageQuality.HIGH/BEST in CPU mode which went away when I used MEDIUM instead, so I don't really trust it.

Also, if your app has a lot of text, LOW can make a big difference in terms of perf, esp. on iPad1.

A

AsterLUXman

Inspiring

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

A

AsterLUXman

Inspiring

Addendum - Tips on increasing scrolling smoothness on iPad1:

Using Air 2.7/CPU mode:

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.
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)
For TextFields, set cacheAsBitmap = true and antiAliasType = AntiAliasType.ADVANCED
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.

E

Elliot Mebane

Participating Frequently

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/

B

boat5

Inspiring

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.

T

Trevor-twenty5eight

Known Participant

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

A

Anonymous

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.

J

jpeitz

Participating Frequently

Content deleted.

How do I delete a post in this forum?

S

sanika Kulshreshtha

Participating Frequently

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

M

Mike0431

Participating Frequently

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.

B

boat5

Inspiring

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.

B

boat5

Inspiring

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

Inspiring

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

M

Mike0431

Participating Frequently

I seem to be in the same situation as you.

I can get it working in gpu mode by setting fullscreen to false but I seem to have poor performance.

Using air 2.6 gpu mode I was nearly at a good speed.

I have been waiting for air 2.7 because of the performance increase but the gpu mode

seems to be 10x worse than air 2.6.

J

J Wixson

Participant

@Mike0431 Are you setting stage quality to high (stage.quality = StageQuality.HIGH) in your application? If so, try setting it to medium (or just don't set it at all) and you should see performance and visuals in line with AIR 2.6.

In AIR 2.6 (and earlier) on mobile platforms, stage.quality was capped at medium. Explicitly setting the stage quality to high had no effect. This changed in AIR 2.7, and the stage quality setting now directly affects the parameters used to configure anti-aliasing performed by the GPU when using the GPU render mode. As you may have discovered, however, this can have a huge performance impact and needs to be applied very judiciously.

M

Mike0431

Participating Frequently

hi julian,

I never set the stage quality originally but tried playing with the code after what you said

and still no luck.

I have no idea why but compiling in air 2.6 seems to give me such a better gpu performance.

I need gpu because cpu is too slow.

Is anyone else having better gpu performance in 2.6?

Y

Yacine__Dooprod_Author

Inspiring

Hi everyone!

And thank you all for sharing your ideas, it's why I love Flash Community!

Coling Holgate wrote
(...) So, it may just be a lot easier to use CPU instead, things look nice there, and the performance can be better than it was with GPU an AIR2.6.

gregdenness wrote
(...) however from what I have seen it doesn't come close to GPU performance under 2.6 - I guess it depends on a lot of factors though. Has the GPU performance been increased on 2.7?

Agreed with Colin! CPU offer a lot, filters, good perf... A very big change since the last build. And like you said Gregdeness, it's true: it depends a lot of the app itself. Even if Air 2.7 is x4 time faster than before in CPU mode, it's not enough for me to run my app as quickly as GPU render. Again, it's only "for me" and for my type of use!

So just to give your an idea, I made a videos.

AIR 2.6 GPU vs AIR 2.7 CPU: ROUND 1 - FIGHT!

So I made a test, the same app with Air 2.6 and 2.7 in different render mode.

(480p minimum please or watch in HD on Youtube!)

First: I create a framework (codename... rePLAY!) for my game.
And it's clearly optimise for the GPU mode (bitmapdata, bytearray, physic, 3D...) It's important to know that before we start!

1/ INTERFACE & MENU

For the intro / menu / level selection, there is no big difference between AIR 2.7 CPU vs AIR 2.6 GPU. A little slow when I split the logo, but it's 1 or 2 frames less.

2/ GAMEPLAY

No big difference here too... Except the aliasing of course in CPU mode, it's like all object is in x2 zoom! But it's normal (no AA filter in CPU). The framerate is the same. BUT what a surprise, filters works! So if you watch the transition, the image becomes black & white after a flash! Cool! It's what I wanted but not working in GPU! Raaah!

3/ AQUARIUM 3D

For the 3D holographic stuff... Ouch! I have a solid 30fps in AIR 2.6 GPU but 10-12fps in AIR 2.7 CPU! And it's not responsive at all.

So, and again I speak for me, it's not the time to switch on Air 2.7 in CPU!
I really want to work with this version in GPU mode but because of the little bug...
And I need to be fullscreen!

But I read a lot of good comment with Flex!
And CPU is more powerful now!

So good work and...

GO ADOBE GO!!

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded