3 ms·
Macros here would make the problem worse. The problem is not notation, it's the call to glBindTexture. It has 1) inescapable measurable performance overhead an
by cscheid 14y ago
Macros here would make the problem worse. The problem is not notation, it's the call to glBindTexture.
It has 1) inescapable measurable performance overhead and 2) affects state that changes the rendering output.
So if you macro it, you're forcing yourself to calling glBindTexture even in the cases where that wasn't necessary. (say, if you had just called glBindTexture and knew that the right texture was bound anyway). And, in addition, you have to remember to store the previous state of the bound texture in case someone down the execution path wants to use that value. Macroing things which change global state is, in general, a terrible idea.
If you don't macro it, your code has to remember whether the right texture has been bound, and design around that. It can be done for sufficiently simple cases, but the general solution also has performance overhead (checking a local variable before calling glBindTexture will get you into branch misprediction problems)
You can imagine complicated solutions like state batching: writing a better, retained-mode domain-specific language atop OpenGL which will analyze the sequences of your calls before making it, and then remove all the unnecessary glBindTexture, etc. calls. But it's a major pain in the ass that simply shouldn't exist.