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).
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.
Okay... I just finish a test and it's that.
= not working as I expected
= working well
= working well
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!
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.
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.
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.
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.
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.
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.
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.
(...) 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.
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!!
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.
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."
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!
@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.
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?
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.
If you're doing a test like this:
var t:Timer = new Timer(100,0);
// 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.
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.
Same Problems... I'm working on a workaround.
Tick, Timout and Interval classes (all based on an unique ENTER_FRAME) :
This is the bug id for the gpu performance issue.
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.
Here is a test file for theTimer bug
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.
Tested on my 3GS, OS4
Compiled with AIR 2.7, renderMode GPU, fullscreen.
Test class here :
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?
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?
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/AdobeTimer Test.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.
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.
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
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.
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