Slow performance on andriod, is it because of lot of transitions?

Audio and Graphics
#1

Hi There,

I have just released my first game “Spiky Fall” on android and ios, it is working perfectly fine on ios without any glitch what so ever.

But on android phone lot of users have reported me that over time my game becomes little sluggish, if they exit and open it again then it will be responsive, i have tested it on my 3 year old nexus 4 and though i had observed little slowness in the game over all the experience was acceptable.

It is a simple arcade game, but i’m doing lot of background transitions (alpha, scale, movement etc in the screen background) using the transition api of corona sdk, will more transitions affect the screen fps and make it sluggish?

i tried seeing the memory usage and seems to be very close to the below range:
 

System Memory Used: 1.405 ~ 2 Mb

Texture Memory Used: 29.540 Mb (constant)

Check out the game play here: https://youtu.be/na7XG_wv7gs

(observe the transitions in the background)

you can download it here (this is not for marketing :)):

android: https://play.google.com/store/apps/details?id=com.omgabird.spikyfall

ios : https://itunes.apple.com/app/id1084213403

Thanks in advance,

Nischal Y

#2

What they describe sounds like a memory leak.  Have you tested the game thoroughly for this?  

Another issue is that there are tens of thousands of different Android devices running different processors and memory, so it might very well be too “heavy” for some.  I would suggest asking these users what device they are using, and then considering making the app unavailable for these devices.

#3

i too assumed that this should be a memory leak, but i’m not able to reproduce it on my 3 year old nexus 4 (may be nexus is a well optimized phone like iphones), i’m still trying to optimize as much as i can, was just wondering if transitions are resource intensive because im using lot of transitions in the background and maybe few android devices are not able to handle all those transitions, and i do agree that the details i provided are too vague to make any conclusion.

But i’m trying to understand if more transitions might cause any issues

#4

Either a memory leak or a process leak.  You said your memory stays constant, so I’d say a process leak.

When I say process leak, I mean you’re creating multiple instances of processes or listeners that over time cease to do anything useful, but still run.  

For example, if you’re adding enterFrame listeners over time and not cleaning them up, they could drag down performance.

I suggest profiling the game:

  1. Early - Delay the profiler  a second or two, while you start the game and get it running (i.e in the play gui)

  2. Delayed profile - Once you have that data, delay the profiler starter for serval minutes and repeat the playing experiment till the profiler kicks off.

Compare the two data sets to see if something is dominating the processes.

http://www.mydevelopersgames.com/profiler.html

#5

Do we have to cancel any ongoing transitions when we go from one screen to another?,

I have a home screen and game screen, in game screen there are lot of BG transitions and when i go from game screen to home screen i’m not cancelling all the transitions, im letting them complete, should be cancel all the transitions?, will this have any affect on the performance.

#6

Well, cancelling the transitions would stop any processing associated with them, so that would be a win.  However, even if you don’t they’ll end eventually so that won’t cause lingering slowness.

#7

Personally, I have found performance issues with transactions occurring on different displayGroups if each displayGroups overlays the other with alpha transparency and you are using blend modes - because of the extra computations required for final rendering.

Make sure you are not firing events more often then you need to - say you have a touch event checking for movement and that event is firing for every pixel moved that can drag performance down.  Store the last event.x and event.y and then only fire events if the delta movement is more than 5 pixels (depending on your config.lua settings).

Try using easing.linear and see if that helps performance?  Others have suggested using enterFrame and modifying x and y using delta values but that makes no real difference so stick to transactions as they take the headache out of delta time calculations.

#8

What they describe sounds like a memory leak.  Have you tested the game thoroughly for this?  

Another issue is that there are tens of thousands of different Android devices running different processors and memory, so it might very well be too “heavy” for some.  I would suggest asking these users what device they are using, and then considering making the app unavailable for these devices.

#9

i too assumed that this should be a memory leak, but i’m not able to reproduce it on my 3 year old nexus 4 (may be nexus is a well optimized phone like iphones), i’m still trying to optimize as much as i can, was just wondering if transitions are resource intensive because im using lot of transitions in the background and maybe few android devices are not able to handle all those transitions, and i do agree that the details i provided are too vague to make any conclusion.

But i’m trying to understand if more transitions might cause any issues

#10

Either a memory leak or a process leak.  You said your memory stays constant, so I’d say a process leak.

When I say process leak, I mean you’re creating multiple instances of processes or listeners that over time cease to do anything useful, but still run.  

For example, if you’re adding enterFrame listeners over time and not cleaning them up, they could drag down performance.

I suggest profiling the game:

  1. Early - Delay the profiler  a second or two, while you start the game and get it running (i.e in the play gui)

  2. Delayed profile - Once you have that data, delay the profiler starter for serval minutes and repeat the playing experiment till the profiler kicks off.

Compare the two data sets to see if something is dominating the processes.

http://www.mydevelopersgames.com/profiler.html

#11

Do we have to cancel any ongoing transitions when we go from one screen to another?,

I have a home screen and game screen, in game screen there are lot of BG transitions and when i go from game screen to home screen i’m not cancelling all the transitions, im letting them complete, should be cancel all the transitions?, will this have any affect on the performance.

#12

Well, cancelling the transitions would stop any processing associated with them, so that would be a win.  However, even if you don’t they’ll end eventually so that won’t cause lingering slowness.

#13

Personally, I have found performance issues with transactions occurring on different displayGroups if each displayGroups overlays the other with alpha transparency and you are using blend modes - because of the extra computations required for final rendering.

Make sure you are not firing events more often then you need to - say you have a touch event checking for movement and that event is firing for every pixel moved that can drag performance down.  Store the last event.x and event.y and then only fire events if the delta movement is more than 5 pixels (depending on your config.lua settings).

Try using easing.linear and see if that helps performance?  Others have suggested using enterFrame and modifying x and y using delta values but that makes no real difference so stick to transactions as they take the headache out of delta time calculations.