Size of texture atlas image file and its effect on performance

[ForgeableSum]

I noticed with the thousands of bunny sprites hopping example that the texture atlas was only 1.5KB... I'm wondering what effect the size of the texture atlas has on performance? 

[Tom Atom]

Hi, I think, that there is no performance impact, because you are passing UV coordinates from vertex shader to fragment shader and there you are picking texels to paint image. If atlas is not used, then these UVs are 0,0 for top left corner and 1,1 for bottom right corner. If atlas is used then you are passing something between this - you just map only part of texture on target quad.

OpenGL has some overhead when switching from texture to texture - this is reason to make atlases. GPU has all that shader units and if you push lot of images from one atlas into it, it gets happy and can process it in parallel. But if you are switching textures, it cannot run parallel and it has to flush previous batch and do settings to prepare for different batch (also switching shaders, changing blending mode, ... all that initiates switches and results in those famous draw calls)

 

Another thing I read somewhere was, that if you have texture (without mip-maps), then OpenGL has very small performance difference in scaling texture up and down (do not remember, whether it was for OpenGL generally or for some specific cards brand). Scaling down should be little more expensive then scaling up. So, making huge texture and then map it to small quad is not good. In my opinion, it is bad more from memory point of view than performance view...

[stupot]

Bigger textures do incur a performance penalty, end of.  It's not at the phaser level, but just about every level of software/hardware in between Phaser and rasterisation of the framebuffer.

 

It's all about memory usage and memory span:

• A larger texture consumes more storage in the fast gpu memory (if present), leaving less room for others which may have to be slowly uploaded to the gpu per render cycle. The time taken to upload textures depends on upload bus speed, bigger textures = slower upload.
• Small areas of graphics data in a large texture are spread out over a wide area of memory, imagine pixel data layed out sequentially, then imagine how much pixel data you have to skip from the trailing edge of one line of your graphic to the leading edge of the next line. If there's a fast memory cache involved then the memory span accessed in a large texture is less likely to hit those small cache blocks. This is especially important for software side processing.

When you consider all the different applications resource requirements, and all the different browsers, and all the different devices, you'll have an infinite number of combinations, so nobody can generally say what the performance penalty is.

 

The reality is that the performance hit for a few large textures probably isn't going to be noticed and maybe not even be measurable on mobile devices, you just have to try it and see.  In a years time, the average hardware spec will be a year better and the problem less of a problem, so don't worry too much about it.

 

The best practice to minimise performace drops is:

• Atlas textures generaly outperform separate textures, use them for production.
• Squeeze as much graphics into your atlas textures, don't waste pixels.
• Try to aim for POT atlas texture sizes, even if you have to waste a little bit
• Prioritise a tall/thin atlas over a wide/short one.
• Minimise texture swapping, group related graphics into an atlas depending on how you draw them so items that are drawn together are in the same texture. 

 

There's optimisations to be done on the initial texture loading stage, but thats another story.