0

We have a game that runs pretty smoothly on Android but the game is unplayably slow on iOS especially on iPhone 4. We have found some candidates what may be delaying the game rendering but still the overall performance is quite bad.

The following insights can be written down:

  • We are quite sure that something in PlayN rendering loop may be the main reason of bad perfomance. Effect of disabling physics simulation and game update computations is marginal, while it is 70% of computing time on Android).
  • There is no significant dependency on screen resolution (retina/non-retina) so insufficient fill rate could be eliminated.
  • Avoiding CanvasLayers and SurfaceLayers usage has only minor effect - most of the game are just moving ImageLayers.
  • Vector text labels rendering (from Triple Play) is slightly slower but marginal.
  • Composite operation is even slower but still not the main cause.

The question/s:

Do you know any other PlayN operation that may be slow on iOS platform and should (and could) be avoided? Is there any way how to get symbols to XCode profiler to get better knowledge of the main holdups in the game? Is there any other tool we can use for PlayN internals profiling?

Thanks for any experience with iOS performance problems.

Blackhex
  • 1,694
  • 3
  • 21
  • 45
  • 2
    Use instruments to identify the bottlenecks. Do not assume, measure! – Till Jan 17 '13 at 20:36
  • We tried but there was no symbols in Instruments with debug build. Who would guess that it have to be release build to show the symbols. Now it is apparent that the main cause IS physics. – Blackhex Jan 18 '13 at 10:14
  • Some further insights about the iOS PlayN peformance are discussed in thread https://groups.google.com/d/topic/playn/RobFg8Lm7jg/discussion – Blackhex Jan 23 '13 at 21:29

1 Answers1

0

Have to say that GWT JBox2d (in PLAYN v1.4,v1.5 last releases) are EXTREMELY SLOW on Android. Just add >50 bodies and it starts hangs and drop down framerate.

Really thinking about Nape or native libs ... Google -_-

Sergey Mukhin
  • 81
  • 3
  • Yeah it´s slow but it can be quite optimized depending on your case. For example by tunning simulation step width, number of iterations, replacing dynamic bodies with sensors and replacing them back when collissions occur, etc. – Blackhex Jan 23 '13 at 21:33