frame stutter...

[mike470]

This happens only on Android devices, and only on *some* of them. For example, it happens on my Toshiba Thrive tablet, but not on my Droid Bionic. Never happens on iOS devices.

The screen updates just stop for about half a second. All sprites playing and transitions happening stop. When transitions resume, they obviously “jump” ahead quite a bit. This is intermittent, and doesn’t follow any particular pattern.

To try to isolate it, I

* removed all mp3 sound playing,
* made absolutely sure nothing is happening inside the “enterFrame” listener (except three or four checks of variables being true or false)
* checked that the timer I have going every second or so is not doing anything (again, except for checking a couple of variables)
* and I turned off garbage collection completely.

The stutter still happens.

The interesting thing is it happens only in two of five animated scenes in the game, and those two are not the most complex ones. So that kills the idea that it is the OS in background screwing things up independent of my code…

Has anyone encountered anything like this and found the fix? [import]uid: 160496 topic_id: 30356 reply_id: 330356[/import]

[Into-It_Games]

Yup sounds familiar, although I don’t think my problem was as bad. I see you mentioned garbage collection and for me that was the problem itself. My device (Optimus 2X) would garbage collect every couple seconds (manual or automatic - did not matter) and in the ddms terminal it would say something like “freeing x-number of objects took 35ms.” I dunno if this is your problem, but its definitely worth hooking up to your pc, running ddms located in the android sdk and seengn what errors, warning, or otehr info your device is spitting out. [import]uid: 164950 topic_id: 30356 reply_id: 121605[/import]

[mike470]

Running logcats, all I get is something like this every 30 sec or so:

D/dalvikvm(10208): GC_CONCURRENT freed 387K, 81% free 6886K/34695K, paused 3ms+3
ms

Cannot be sure whether those coincide with stutters, but they are claiming 6-10ms or so, the stutters are more like 200-400 ms…

On edit: ok, I *think* I saw something show up that coincided with a stutter:

I/dalvikvm-heap(10324): Grow heap (frag case) to 9.769MB for 3145744-byte allocation

No idea what that is though. I don’t think there is anything around my code in there that allocates 3M worth of stuff.

By the way - I am pretty sure there are no memory leaks. At least when I go in and out of an animated scene and after collecting garbage compare the texture memory and lua memory there is no increase in texture memory and a miniscule (<1K) increase in lua memory… [import]uid: 160496 topic_id: 30356 reply_id: 121606[/import]

[mike470]

Update (for people who find this thread who are having the same problem)

Doing collectgarbage(“collect”) every second on a timer cured the problem. So I guess it is garbage collection, but not sure why the logcats don’t show it.
[import]uid: 160496 topic_id: 30356 reply_id: 121709[/import]

[Joshua_Quick]

The stutter is being caused by the Java garbage collector. You are doing something in your code that is causing large memory allocations on the heap frequently.

Are you updating text often? Such as a frame rate (FPS) counter?

Just a warning, updating text is very expensive. Every time you update text, Corona has to generate a new bitmap in memory, draw text to that bitmap, and then submit that bitmap to OpenGL as a texture. Also, the larger the text, the bigger the bitmap has to be, which means an even bigger memory allocation and a bigger performance hit. All of these memory allocations causes havoc with the Java garbage collector causing it to collect garbage frequently, which is another major performance hit.

So, bottom line, updating text is extremely expensive and you do not want to update text on every “enterFrame” event.

If you absolutely have to update text frequently, then I suggest that you use “bitmap fonts” instead, where all the numbers and letters you need are in a single spritesheet that is preloaded into memory. You would then assemble your words with these sprites. This is a very common technique used by games to hugely improve performance. It’s great for updating onscreen scores, times, or whatever. I know our CodeExchange has at least one bitmap font Lua library submitted by a member of our community. You might want to check that out.

I hope this helps! [import]uid: 32256 topic_id: 30356 reply_id: 121722[/import]

[mike470]

Joshua, the only thing it was doing was updating the timer text every second. Is that enough to cause problems? [import]uid: 160496 topic_id: 30356 reply_id: 121728[/import]

[Joshua_Quick]

If you are only updating text once a second, then worst case, the garbage collector should only be going off once a second.
[import]uid: 32256 topic_id: 30356 reply_id: 121739[/import]

[mike470]

Well, I found that if I preemptively do collectgarbage myself, every second, then there is no stutter. The stutter I experienced before was about every 20 to 30 seconds. [import]uid: 160496 topic_id: 30356 reply_id: 121744[/import]

[Joshua_Quick]

Hmm… I’m thinking that your app is creating/destroying a lot of objects per frame. The Lua runtime might be lazy about destroying objects on the heap that are no longer referenced in your app, so the heap grows and grows until the Lua runtime decides to collect garbage. That would explain why you calling collectgarbage() works-around this problem. Or perhaps another solution would be to re-use discarded Lua objects, thus avoid the memory allocation/deletion penalty completely… if it’s possible in your program.

Anyways, that’s my 2 cents.
I’m glad you’ve found a way to solve it. [import]uid: 32256 topic_id: 30356 reply_id: 121887[/import]

[mike470]

Does changing sprite scales eat up memory that needs to be garbage collected? [import]uid: 160496 topic_id: 30356 reply_id: 121901[/import]

[Joshua_Quick]

Scaling does not cause any memory allocations to occur. That should be a cheap operation.

I’m curious… if you comment out the text updates in your code, does the stuttering go away? [import]uid: 32256 topic_id: 30356 reply_id: 121914[/import]

[Into-It_Games]

Yup sounds familiar, although I don’t think my problem was as bad. I see you mentioned garbage collection and for me that was the problem itself. My device (Optimus 2X) would garbage collect every couple seconds (manual or automatic - did not matter) and in the ddms terminal it would say something like “freeing x-number of objects took 35ms.” I dunno if this is your problem, but its definitely worth hooking up to your pc, running ddms located in the android sdk and seengn what errors, warning, or otehr info your device is spitting out. [import]uid: 164950 topic_id: 30356 reply_id: 121605[/import]

[mike470]

Running logcats, all I get is something like this every 30 sec or so:

D/dalvikvm(10208): GC_CONCURRENT freed 387K, 81% free 6886K/34695K, paused 3ms+3
ms

Cannot be sure whether those coincide with stutters, but they are claiming 6-10ms or so, the stutters are more like 200-400 ms…

On edit: ok, I *think* I saw something show up that coincided with a stutter:

I/dalvikvm-heap(10324): Grow heap (frag case) to 9.769MB for 3145744-byte allocation

No idea what that is though. I don’t think there is anything around my code in there that allocates 3M worth of stuff.

By the way - I am pretty sure there are no memory leaks. At least when I go in and out of an animated scene and after collecting garbage compare the texture memory and lua memory there is no increase in texture memory and a miniscule (<1K) increase in lua memory… [import]uid: 160496 topic_id: 30356 reply_id: 121606[/import]

[mike470]

Update (for people who find this thread who are having the same problem)

Doing collectgarbage(“collect”) every second on a timer cured the problem. So I guess it is garbage collection, but not sure why the logcats don’t show it.
[import]uid: 160496 topic_id: 30356 reply_id: 121709[/import]

[Joshua_Quick]

The stutter is being caused by the Java garbage collector. You are doing something in your code that is causing large memory allocations on the heap frequently.

Are you updating text often? Such as a frame rate (FPS) counter?

Just a warning, updating text is very expensive. Every time you update text, Corona has to generate a new bitmap in memory, draw text to that bitmap, and then submit that bitmap to OpenGL as a texture. Also, the larger the text, the bigger the bitmap has to be, which means an even bigger memory allocation and a bigger performance hit. All of these memory allocations causes havoc with the Java garbage collector causing it to collect garbage frequently, which is another major performance hit.

So, bottom line, updating text is extremely expensive and you do not want to update text on every “enterFrame” event.

If you absolutely have to update text frequently, then I suggest that you use “bitmap fonts” instead, where all the numbers and letters you need are in a single spritesheet that is preloaded into memory. You would then assemble your words with these sprites. This is a very common technique used by games to hugely improve performance. It’s great for updating onscreen scores, times, or whatever. I know our CodeExchange has at least one bitmap font Lua library submitted by a member of our community. You might want to check that out.

I hope this helps! [import]uid: 32256 topic_id: 30356 reply_id: 121722[/import]

[mike470]

Joshua, the only thing it was doing was updating the timer text every second. Is that enough to cause problems? [import]uid: 160496 topic_id: 30356 reply_id: 121728[/import]

[Joshua_Quick]

If you are only updating text once a second, then worst case, the garbage collector should only be going off once a second.
[import]uid: 32256 topic_id: 30356 reply_id: 121739[/import]

[mike470]

Well, I found that if I preemptively do collectgarbage myself, every second, then there is no stutter. The stutter I experienced before was about every 20 to 30 seconds. [import]uid: 160496 topic_id: 30356 reply_id: 121744[/import]

[Joshua_Quick]

Hmm… I’m thinking that your app is creating/destroying a lot of objects per frame. The Lua runtime might be lazy about destroying objects on the heap that are no longer referenced in your app, so the heap grows and grows until the Lua runtime decides to collect garbage. That would explain why you calling collectgarbage() works-around this problem. Or perhaps another solution would be to re-use discarded Lua objects, thus avoid the memory allocation/deletion penalty completely… if it’s possible in your program.

Anyways, that’s my 2 cents.
I’m glad you’ve found a way to solve it. [import]uid: 32256 topic_id: 30356 reply_id: 121887[/import]

[mike470]

Does changing sprite scales eat up memory that needs to be garbage collected? [import]uid: 160496 topic_id: 30356 reply_id: 121901[/import]