sudden performance drop on android

[NickoftheSouth]

Hello,

I'm developing a game using MOAI and so far progress has been great and I'm really impressed with what it can do.
I've been using a windows machine as my development envrionment, testing it in windows and pushing it to my android phone and another android tablet for futher testing.
A colleague has been publishing to iOS devices using his mac.
The game runs fine under windows and iOS but recently has had performance usses under android.
Since the client only requires iOS to start out so at this stage this isn't a major problem, but some time in the future there is a likely possibity that they will request an android version.

The problems seem to be releated to displaying text, spefically changing the string of a text box.

The game esspessialy slows down in a summary screen that counts through the score earned and the bonus score for remaining time.

I've created one font object to use through out the game, but perhaps have set the scale to be a bit big and it (?) uses too much texture memory.
If it roll my own font using a sprite sheet will this likely result in better preformence?
The other advantage of this is more control over how the font appears (color texture outlines, ect.)

Thanks in advance for any tips or suggestions

[ibisum]

A couple of points:

1. Are you using the moai-dev branch for your build of the MOAI client on Android/iOS/Windows/etc? The reason is: there have been some bugfixes related to Android performance in the last few weeks, and maybe you've missed these? I seem to remember there being a critical bug fixed recently which changes the performance of the optimized GL pipeline (I'd suggest you check the Issues history of the moai-dev repo).

2. Performance with textures is not as 'evenly distributed' across the Android targets as it is with iOS. Whereas Apple have done everything they can to optimize the GLES1/2 pipelines on their platform, not all Android vendors follow suit - so it really depends not only on Android vs. iOS, but also "Android phone A" versus "Android phone B". When possible, try to test for Android on both high-end devices, *and* low-end devices - the differences in the GL ES stack implementation from both vendors can be, frankly, shocking and disappointing. You have to account for poor Android implementations in your test strategy - not so much with iOS, however.

3. Fonts can eat up your render pipeline cache pretty darn fast. I would say that a re-examination of the font-using strategy applied in your app would be beneficial - but do yourself a favour and test on more than one Android device before you dig in too deep on this issue - as you'll need such a test process to ensure your font strategy is working properly. There are tradeoffs between using a big texture-sheet generalized for 'all text', and creating a texture sheet with *only the glyphs you are using in your app* .. if you never use the symbol '*' in your app, for example, then exclude it from your texture sheet .. well, this is a lot of fuss and hassle, so thats why I say check your performance metrics against more phones.

[NickoftheSouth]

Thank you very much I'll check through those points.

I think the android host we are using is at least a week old and I don't think it is the dev branch, so I'll get the latest.
The phone I've been testing on is probably considered middle range (HTC Wildfire s) and the tablet is also middle as far as tablets go (Lennov K1) and at the moment those are the higest end devices I have access to.
I'm sure the HTC at least is capable of fairly decvient opengl rendering since I've been deleloping a fps game on it in my spare time and that includes dozens of textures (some quite large) and numirous surfaces.

I don't have a problem having a second set of textures for android that are smaller or have a smaller palette, the focus is on preformance.

Thanks again