Does the order of switching states and property settings affect performance?
for example:
glEnable(GL_TEXTURE_2D) after or before glEnable(GL_BLEND),
or if it’s enabled after specifying texture enviroment/object settings?
states are generally flushed when you call a drawing function, so the order will be irrelevant.
why not just do your own test program instead of taking our word for it?
Because tests do only reflect the behavior of the tested system.
There could be some documents by IHVs advising this usage pattern or that for a whole family of systems…
I have never seen such a documents.
Knackered is right - the best solution is to write what you need and to see what you get.
There is common and useful advice like making your own states management cachuing system to prevent from extra states switching and driver calls. This won’t be bad anyhow.
Wrt. performance the order of state changes shouldbe irrelevant for the implemenations doing lazy validation. But there is at least one exception to the order of calls which is color material. The explanation can be found in pitfall #14 here: http://www.opengl.org/resources/features/KilgardTechniques/oglpitfall/
My personal OpenGL code guideline is to always set state first and then enable it.
Other than that, the fewer state changes, the better.
Bad OpenGL programs define a default state and always return back to it, good ones implement their own state cache and set what they need when they need it, and if the state doesn’t change, don’t call into OpenGL at all.
Like Relic already pointed out there are certainly a number of operations that depend on the ordering of your GL calls.
e.g. Eye linear automatic texture coordinate generation depends on the value of the modelview matrix at the moment the function is called.
N.