A little probleme with Air 2.7 in GPU?

Report · Jun 15, 2011

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!

Report · Jun 15, 2011

Well, I had this too.

From my point of view (right now) it might not be a little bug, since I guess it is what they mean on http://kb2.adobe.com/cps/906/cpsid_90612.html by saying:

AIR on iOS

• stage.orientation property incorrectly returned when started on landscape. (2852193)

So this is a known bug and it hasn't been fixed.

Report · Jun 15, 2011

Hi,

This issue is known to us and it happens only in when is set to true in application.xml. I would suggest you to set fullScreen to false or use CPU mode.

-Sanika

Report · Jun 17, 2011

@josholm

Here's the workaround that the Flex team has used for this issue:

"Instead of querying the orientation property on Resize event, query the orientation property in OrientationChange event. Value of orientation property you are getting in Resize event is not the latest updated value."

Report · Jun 17, 2011

Hi Scott,

thanks for the info. I will give this a try and hope that this is a way to make a smooth experience.

Report · Jun 15, 2011

Okay... I just finish a test and it's that.

--------------------------------------------------

Test 1

= not working as I expected

--------------------------------------------------

Test 2

= working well

--------------------------------------------------

Test 3

<fullScreen>false</fullScreen>

= working well

--------------------------------------------------

For my app I need to be in GPU mode / Fullscreen. I don't want the iPhone top bar on the screen. I think a will stay on Air 2.6 for the moment. Not a big problem! I just wanted to test and share here because I think it will be soon a recurring problem on this forum!

Thanks Sanika and Josholm!

Report · Jun 15, 2011

Hi Sanika,

in my opinion there are still several issues with the orientation/fullscreen modes.

I think that AIR just hasn't been testing in landscape mode a lot and also not the autoorientation feature, which takes a lot of effort to adjust it so is just working (but still far away of being compareable to a native app). I really like the AIR idea, but it is really a little annoying that certain basic things are still missing in these builds – and now fullscreen/GPU is just not possible to use...

But hey, thanks for being here and helping out!

Josh

Report · Jun 16, 2011

Yeah this happens to me as well running gpu and fullscreen.

I cannot believe Adobe would mess up like this, this means that basically that we can't use 2.7 as we need fullscreen games. This has been working since packager for iphone and is now broken.

Back to 2.6 I guess.

Report · Jun 16, 2011

I am really disappointed that this slipped through the cracks. The GPU rendering + fullScreen + landscape mode combo is widely used by many apps, especially games. 3/4 of my apps are affected by this, as they rely 100% on the fast GPU rendering of bitmaps.

Report · Jun 16, 2011

An existing work around to the strange landscape size issue was to have the app set to portrait, and then change it to landscape once the app is running. That work around continues to work.

There are many other changes though, so if you are going from an AIR2.0 app to update it to AIR2.7, there are more serious changes you'll need to make. Such as vectors not being antialiased, and filters being lost. 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.

Report · Jun 16, 2011

CPU performance is better, 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?

Thanks for the tip about the workaround.

Report · Jun 16, 2011

GPU isn't really changed much from 2.6. CPU is quite a lot better, and some of the time consuming work arounds you have done before can be taken out. For example, if you had a large vector graphic that you wanted to move around a lot, you would have cacheasbitmap and cacheasbitmapmatrix, which takes a significant amount of time to do. Once it's done the image would fly around the place ok, but if you misjudged the size of the resulting bitmap, you could get into a situation where the bitmap is constantly uploading to the GPU. By taking out all of that optimizing code, the CPU version will work better.

That isn't to say that cacheasbitmap on its own isn't worth doing, it may speed up the drawing of things to the stage, but you don't need to cacheasbitmapmatrix things, the transfer of the entire stage image to the GPU is very fast now.

Report · Jun 16, 2011

Thanks for the workaround. It does the trick, but it looks a bit funky when it rotates the stage on startup. I tried showing a black screen until the orientation change event has fired, but that resulted in a few seconds of waiting between the splash and the app showing up.

So I went back to 2.6 and didn't find any noteworthy performance differences with GPU rendering. I'll stick with that for now.

Report · Jun 16, 2011

Just as a point of interest, the settling down of portrait to landscape is reasonably quick, I think I just had a half second of blank stage to cover up the effect.

Report · Jun 16, 2011

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

Report · Jun 17, 2011

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.

Report · Jun 20, 2011

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

Report · Jun 21, 2011

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?

Report · Jun 21, 2011

Hi Mike,

For the GPU performance issue, could you file a bug at http://bugbase.adobe.com and post the bug number here? Please try to attach a simple test application which can demonstrate the bug. You could also mail it to me directly at sanika@adobe.com

Thanks,

Sanika

AIR team

Report · Jun 21, 2011

Hi sanika,

I will file a report.

I have tested out my app more with air 2.7 and have noticed a delay in the timer.

The amount of time seems to be longer than the time set.

maybe the performance issues are to do with the timer.

Report · Jun 21, 2011

If you're doing a test like this:

var t:Timer = new Timer(100,0);

t.addEventListener(TimerEvent,check);

t.start();

function check(e:TimerEvent){

// do some demanding things

}

and you're finding that the average time between events is more than 100 milliseconds, that's normal behavior. The time it takes for your routine to run is added on to the timer's cycle. Otherwise, in a worse case, you could get another timer event arriving while you're handling this one.

If you need precise timing, like if you have a playback head following a timeline, there is a way to do that.

Report · Jun 22, 2011

The timer is completely wrong.

I set a 20 second timer event and the event is being called either too early or too late.

The timer is inaccurate by seconds not milliseconds.

Sometimes the timer event was called too early or too late by over 10 seconds.

I compiled for both air 2.6 and 2.7

and the problem only happens when compiled with the air 2.7 sdk.

Report · Jun 22, 2011

Same Problems... I'm working on a workaround.

Tick, Timout and Interval classes (all based on an unique ENTER_FRAME) :

https://github.com/jonasmonnier/Mobilo/tree/master/src/com/mobilo/time

Test :

https://github.com/jonasmonnier/Mobilo/tree/master/src/test

Report · Jun 23, 2011

Hi jonas,

Thanks for the workaround.

Glad to see i'm not the only one with this problem.

My app uses the timer a lot.

When/if this is fixed I hope to see a good gpu performance.

Report · Jun 24, 2011

@Mike Do you try my Interval class ?

I'm not sure that resolve this bug will improve performance in GPU renderMode.
My application with AIR 2.7 + Interval stay less efficient than with AIR 2.6...

Adobe Community

A little probleme with Air 2.7 in GPU?