Adobe AIR Development

[shawnblais]

---

owen_ wrote:

So I created a very simple app with just a buffer texture, a text field for the elapsed time and a loop drawing out a 1x1 texture in randomized points across the screen.

The app runs ok with a handful of sprites on screen, but by the time you have ~200 or so the framerate is at 20fps. I then tried the same app with GPU rendering enabled and the performance actually decreased! It was hovering around 24fps with nothing being drawn.

I suppose 200 sprites is quite a few, and maybe I was just expecting more from the Playbook. But this is a very simple app with no logic involved even, just simple rendering. It just seems like a device with such highly touted Flash performance would fare better than this.

---

The trick to GPU mode is to always reuse the same textures (in this case bitmapData). Try that same test, but make sure each sprite holds a bitmap that shares the same bitmapData object, you should hit 60fps without any problems.

Then it's just a matter of re-architecing your game to cache all bitmapData instances, and reuse them anytime somethign needs to be rendered.

It's actually a much simpler concept than blitting, as you can use the displayList again, rotation, scale, alpha, parent:child, all work without issue.

[shawnblais]

With that said I think RIM kinda screwed up GPU mode in the last version of AIR and have never fixed it.

Your problem is that you're stuck with the idea that blitting is the fastest approach. It's not the case on a device like this. You are asking it to push a full 1000x600px frame buffer to the GPU every frame and it's just never gonna run well... that's why you can never get over 30fps, you're using a desktop based technique which is roasting your mobiel ARM cpu.

As a comparison, run your blitting engine on desktop with a canvas size of 2400x1200 px... see how that runs. It will melt your CPU, it's just too many pixels for the limited cpu > gpu bandwidth. it doesn't matter if the canvas is completely empty.

CPU mode with normal display list is pretty quick on playbook, (but make sure to keep your dirty regions in check) GPU mode usesd to be excellent, but like I said, I think they borked the implementation unfortunately.

[dmalik]

There are a number of limitations with GPU mode. For a full list please visit Adobe's site here - http://help.adobe.com/en_US/as3/mobile/WS901d38e593cd1bac-3d719af412b2b394529-8000.html

RenderMode=gpu is supported as best effort only. If it works for you great, if it doesn't, file a bug and we will try to fix as we can. 

[owen_]

Thanks for the info guys. I might try it again with re-using my bitmaps, and I hadn't seen that limitations document before so it's good reference to have.

[bobbydriscol]

One last thing you may want to try is switching from tweenlite to tweener which is included in the qnx swcs (not sure if it's been converted into the ANE's for that performance boost off the top of my head. Tweener is integrated with qnx and would be the best tweening engine to use (and the coding is very similar).

The other thing to try is setting your stageQuality to Medium rather than Best or High. Might help with a few frames per second rendering since the anti-aliasing is switched to 2x2.

All the best.