Desired sizes for images

A few weeks back on some web link I saw a post where someone was saying that it is preferred that image files be of a desired width and height, because they load faster. The post said something about making image dimensions a power of 2, because they load faster.

Has anyone heard of anything like that? If true, then I take that to mean images combining any two dimensions from a power of 2 ==> (2,6,4,16,32,64,128,256,512, etc.)

1 Like

Yes, the GPU prefers texture sizes that are two’s compliment.

2,4,8,16,32,64,128,256,512,1024,2048,4096,8129 etc…

2 Likes

Some drivers actually force power of two textures.

So if you define a texture to be 1025 by 1025 it will actually be 2048 by 2048 as far as the GPU is concerned.

1 Like

No, it does not re scale the texture, it just preferes twos compliment sizes.

1 Like

Thanks Guy’s great answers. Very informative.

Wrong.

There is no scaling, but in GPU memory the size of the texture is promoted to the lowest power of two it fits in.

You can check to see if the combination of GPU and drivers supports NPOT textures but there are still combinations out there in the wild that don’t

1 Like

I get what you are saying, NPOT will be put in a POT sized lump of memory on the GPU. I dont think what I said was wrong as the GPU does prefer POT, NPOT textures can end up being slower to access due to this.

This form the Unity docs:

“NPOT Texture sizes generally take slightly more memory and might be slower for the GPU to sample, so it’s better for performance to use power of two sizes whenever you can. If the platform or GPU does not support NPOT Texture sizes, Unity scales and pads the Texture up to the next power of two size.”

I guess you could do the same in code, load the texture, check the size, scale it as need be, then use it. If in doubt, go POT

2 Likes

Instead of just listening to the internet wisdom it can sometimes benefit you to run your own tests and see what the difference is. I had an android game (not monogame) that I updated the images to be in sprite sheets instead of stand alone and it actually slowed the game down. But I suspect that perhaps android is secretly packing it when it builds a package and it’s more efficient than my packing.

1 Like