Some things to try / places to look:
- Make sure the stage quality is set to medium ( stage.quality = StageQuality.MEDIUM ).
I would also try low ( stage.quality = StageQuality.LOW ). If you still want the fonts to look ok with the low setting, for all your text fields, try antiAliasType = AntiAliasType.ADVANCED.
- Unless you absolutely need full-color, I suggest in the Android app manifest to use: <android><colorDepth>16bit</colorDepth></android>. Usually one can't tell the difference, and you will gain a few fps.
- If you are using the GPU render mode, try reducing the resolution of your textures in half and see what it does ( cacheAsBitmapMatrix = new Matrix( 0.5, 0, 0, 0.5 ) ).
- If you are using the Direct render mode + Stage3D, there are a lot of things you can do to maximize performance. Here are a few:
- If you are using a lot of shaders, try rendering your geometry to an intermediary frame buffer whose resolution is user-selectable ( you can call it "grahics quality" ). This way, most of your shaders will run on fewer pixels than the final backbuffer ( which is usually stage.stageWidth * stage.stageHeight: that can be an overwhelming number of pixels on some mobile devices, depending on what you expect your shaders to do ). You will need to apply your frame buffer to a full-screen quad and render it at the end into your backbuffer.
- If you are setting intermediary frame buffers, make sure to keep them as Powers of 2 ( don't use context3D.createRectangleTexture() ), as it is way slower on some devices ( ex: Kindle ) but not all. Note createRectangleTexture is a misnomer, since it means non-power of 2 ( not "rectangular" as opposed to "square" -- createTexture() can be rectangular, but they are POT ).
- I also recommend using mipmaps on all your textures, as this will increase the coherency of the texture lookups ( maximazing the efficiency of the texture cache ). Don't forget: if you do use mimaps, to follow setProgram( ... ), with setSamplerAt( ) to set up what kind of mipmaping use you want ( "mipnearest", or "miplinear" ) -- You can also specify that in the shader, but you might as well do it in AS3 and try different combinations ( more flexible ).
- When requesting the context ( Stage3D.requestContext() ), make sure to try the BASELINE_CONSTRAINED, first. This will definitely speed up the delay in requesting ( on Nook Color, went from 15 secs to 7 secs in one of my apps ). Not entirely sure if it increases performance though.
- Try limiting the maximum texture size for all your bitmaps to 1024 or lower, and see how it looks. This will speed up the texture lookups on devices with very high-res screens ( maximizing texture cache coherence ).
- Try limiting the number of redundant render state changes. Ex: no need for two setBlendFactors() calls within the same frame, if the values haven't changed. Likewise for setVertexBuffers(), etc.
- As a general policy, once the device's dimensions are known, it is usually best to turn all your static vector art into bitmaps, wherever you can. I personally like to do it manually with BitmapData.drawWithQuality(). Otherwise, be very careful with the regular cacheAsBitmap if you are going to rotate or scale things, as it will force the re-caching every frame -- though that should be somewhat obvious.
- You should also install and run Adobe Scout ( free ), to profile what is going on in your app. Graphics is the usually the biggest hurdle, but you might find that some functions are taking too long, maybe.
Note: the Nook Color is the very lowest end, and I use it as a benchmark for optimizing for the worst case scenario on Android. Fill-rate on that device is attrocious, but there is a GPU, fortunately, so overall performance is not as bad as it could have been. I don't think this is the case with the Nook HD in the link, though.
4
Replies
AdChoices