Is it possible that if I'm making a a simple drag-n-drop game, does making a new sprite via constructor with texture as a parameter makes the game slower and depletes more memory until it crashes or does making a new texture via constructor cause the memory to go slow? I'm on a revision for the new drag-n-drop puzzle game where the only goal is to stack the most no. of objects as you can before it falls off the platform. Is it a good idea to create another sprite with texture as a parameter every time a player drag-n-drop another object?

Here's the start of the dry run looked like and I set it to debug mode so that the platform is completely block the pit to test the replication test.

enter image description here

Afterwards, when it reaches from hundreds to thousands, this will be like this and the game gets slower.

enter image description here

When the game crashes, here's the result via Logcat:

12-11 16:38:53.953: E/AudioTrack(25701): AudioFlinger could not create track, status: -22
12-11 16:38:53.953: E/SoundPool(25701): Error creating AudioTrack
12-11 16:38:53.993: D/dalvikvm(25701): GC_EXPLICIT freed 947K, 14% free 14414K/16672K, paused 2ms+4ms, total 96ms
12-11 16:39:16.363: E/AudioTrack(25701): AudioFlinger could not create track, status: -22
12-11 16:39:16.363: E/SoundPool(25701): Error creating AudioTrack
12-11 16:39:16.433: D/dalvikvm(25701): GC_FOR_ALLOC freed 2120K, 15% free 14418K/16848K, paused 47ms, total 47ms

By the way, I'm using BodyEditor library for Box2D program and rendering, a physics engine.

  • 2
    \$\begingroup\$ I doubt it's your sprites causing that. Physics just isn't exactly cheap. A 1000 objects on mobile phone is prone to slow things down. In any case make sure you pack your textures. There is a free LibGDX sprite packer. code.google.com/p/libgdx-texturepacker-gui \$\endgroup\$
    – Sidar
    Dec 11, 2013 at 9:45
  • 2
    \$\begingroup\$ Always always profile before optimising! Always always! Are you sure it's your sprites that lag? \$\endgroup\$
    – Anko
    Dec 11, 2013 at 13:45
  • \$\begingroup\$ As far as I know, @Anko, first is the physics frame that traces around the frame. Secondly, I always use or call to create new Texture in order to replicate random images. I might wonder that normally that getting the images file from ASSETS folder many times for every new Texture is created gets slower or depleting the speed slower. \$\endgroup\$ Dec 11, 2013 at 14:06
  • \$\begingroup\$ @David I don't understand. I'm just asking if you've measured the source of the lag with a profiler tool. \$\endgroup\$
    – Anko
    Dec 11, 2013 at 16:12
  • \$\begingroup\$ @DavidDimalanta It's more efficient if you load a single texture image( TextureAtlas/Spritesheet) and then use a atlas region instead of loading the texture image over and over. \$\endgroup\$
    – Sidar
    Dec 11, 2013 at 18:29

2 Answers 2


The use of keyword new results in costly allocation to heap memory during play.

On mobile apps (not only!), you should always pre-allocate your maximum number of objects, and assign them to an object pool. During initialisation, create an object pool consisting of say, 200 objects. Whenever a object is to be created or destroyed, you simply take one from the pool, or put it back into the pool, respectively. The pool is simply a list holding references to existing, unused objects. In some implementations, it's a class wrapping that list and providing pool access methods.

This pooling approach should apply to your box2d objects and your graphics objects like Sprite; for that matter, any object which is used to compose your "Fruit" entities.

  • \$\begingroup\$ Hmm...performance issues. Do rendering static/dynamic bodies consumes a lot of memory? I set the texture and initialized only once and shared through using a simple array without creating another new texture. The efficiency went a half faster but still laggy. Is there another example on how to make object pool. I want to know more, please? \$\endgroup\$ Dec 12, 2013 at 4:09

You should be able to create a lot more sprites than you've currently got, as long as you don't create a new Texture each time.

From your pictures, you seem to use textures more than once, so you should be able to have something like:

// In some class that manages sprite textures
Texture blueSquareSmiley = new Texture(...);
Texture yellowSquareX = new Texture(...);

// Then where you create your sprites
for(... 1000 times ...) {
    Sprite aBlueSquareSmiley = new Sprite(blueSquareSmiley);

That's how you should be able to manage your textures.

Based on your Logcat, it looks like either the Audio system can't allocate something (could be some other application though) or perhaps the is GC being busy (though it is freeing stuff on the order of 1MB which isn't much).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .