I’m wondering if I should be careful about not creating too many textures in an openGL program. (I’m doing some premature optimization here)
I’ve created an editor that lets users add images to a HUD. A lot of these will be small, independent images for a user interface. The most straight forward way to do this is to allocate a new texture for each image - however, I could end up with hundreds of tiny textures this way. I could also combine them all into a single image and use texture coordinates to map the right subregion of the image.
If I go the many images route, do I have to worry about exceeding some ‘maximum number of textures’ limit? Is this generally considered good practice? If I do combine everything into a single image, is there a way I could get texture effects like GL_CLAMP_TO_EDGE or GL_REPEAT even if I’m only reading from a small area in the middle of the texture?
The problem with many textures is that binding textures takes a little bit of time, normally this is to small to even bother, but if you are binding a lot of them for each frame then obviously it’s going to take a little bit more time.
If we are talking about many many tiny images (32x32 or something like that), then a texture atlas is the way to go, in that case you could use a shader to obtain those texture effects.
If the images are a bit larger like 256x256 or more, then using a texture array would probably be a better choice.
A second problem is that you’ll have substantially smaller draw call batches. Yes - to head this one off at the pass - I know that this is more of a problem for D3D than for OpenGL, but draw calls are still not free in OpenGL either, and each does have a cost. So batching multiple primitives into a single draw call remains a performance win.