Low framerate when use large textureRegion in libgdx

0
votes

This is how I've done:

  1. Create textureAtlas with min. Filter = Nearest and mag. Filter = Nearest.
  2. Get a TextureRegion from textureAtlas.findRegion().
  3. draw it to screen using SpriteBatch. It's very simple, but when I draw a large region(480x320 in my case) the frame rate is slowed down awfully!

drawing 1-30 regions is 30 fps normally, but just 1 large 480x320 region is only 20fps!

3
androidtextureslibgdx
480x320 is not large. A mediocre android device should be able to handle a couple of 1028x1028 textures without issues. Post your code so we can analyze it a bit further. Any additional info like the device you are using to test and it's age would be useful too. – Madmenyo

3 Answers

4
votes

Are you running this on the emulator? The emulator is not an indicator for real-world performance of your application, ever. Test on a real device.

That being said: on common Android devices you can fill the screen about 1.6-2 times. This number is of course just a ballpark number, and influenced by factors such as wether blending is enabled (worse if enabled), filtering (near, linear, the better the more processing power is necessary), your texture's color depth (16-bit RGB, 32-bit RGBA, the higher the more bandwidth is needed).

While not part of your problem, you should also avoid switching textures as much as possible. This for example would be an anti-pattern:

batch.begin();
batch.draw(tex1, 0, 0);
batch.draw(tex2, 10, 30);
batch.draw(tex1, 40, 20);
....
batch.end();

This can be solved by grouping drawing of the same texture or using a texture atlas.

2
votes

If you haven't already read it then you may find this article useful. It describes performance characteristics when drawing large textures.

1
votes

as far as i know, when drawing many regions, a part of the draw commands are send to the GPU for rendering, while you're still adding new draw commands to the spritebatch.
this occours when the size of the batch is reached, a new texture is bound or flush() is called.
if i understood the documentation right, this way cpu and gpu don't have to wait so long for each other and a performance boost is gained.
however, if you have only one draw command of a large region per frame, the spritebatch can't partially send the commands to the gpu since...well...there is only one^^

if you really want to draw only one sprite, you could split it into several regions... (as you said, you have 10fps more)
but i guess once you have to draw more sprites besides of the large one, there'll be no need to split it.