Copy link to clipboard
Copied
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!
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
@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...
Copy link to clipboard
Copied
Hi Sanika,
This is the bug id for the gpu performance issue.
2904026. https://bugbase.adobe.com/index.cfm?event=bug&id=2904026
Copy link to clipboard
Copied
Here is a test file for theTimer bug
https://github.com/jonasmonnier/Mobilo/blob/master/src/test/AdobeTimerTest.as
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
@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
Copy link to clipboard
Copied
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!
Copy link to clipboard
Copied
Would be interesting to hear if you find it fixes things on Android too.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Content deleted.
How do I delete a post in this forum?
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Hi Mike,
Thanks a lot for testing it. Appreciate it!
Regards,
Sanika
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
The timer bug has been fixed.
How can I test the air sdk.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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/
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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
Crash type #2: Switching between an Air 2.7 CPU app and GPU app on iPad1
My advice to developers:
Copy link to clipboard
Copied
Addendum - Tips on increasing scrolling smoothness on iPad1:
Using Air 2.7/CPU mode:
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.
Copy link to clipboard
Copied
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.