Original Article: http://www.egroups.com/list/opengl-gamedev-l/?start=11533 Ben Carter writes: > > Hmm.. Here's a question - is it worth optimising out redundant state > changes? In other words, if I do : > > glEnable(GL_TEXTURE_2D); > > glEnable(GL_TEXTURE_2D); > Generally, yes. There's usually a validation step that's scheduled after a call to glEnable(). It updates the internals caches and what not based on state that was set prior to the enable call. Its difficult to estimate what every driver does, but there's still internal updating that probably occurs. Additionally, its much better to write, for example: glLightfv( GL_LIGHT0, ... ); glLightfv( GL_LIGHT0, ... ); glLightfv( GL_LIGHT0, ... ); glEnable( GL_LIGHT0 ); glEnable( GL_LIGHTING ); than the opposite. Its less important to do this in initialization, but if you're dynamically changing things like lighting or texturing, you'll only validate on the glEnable(), as compared to each glLight() call if you glEnable() first. > Is there going to be a performance hit from the second glEnable call? > Would it be worthwhile writing a wrapper around the state system that > kept the current state somewhere and only made calls that were > necessary, or are the drivers smart enough to do that? Some drivers might be smart enough, but I think the underlying assumption is that its easier to just reprocess like something's changed, than actually try to keep track of which state's changed, and localize that validation. The wrapper idea could be useful; I guess it depends if the apps design can't guard against it. FWIW. Thanx, Dave --------------------------------------------------------------------- Dave Shreiner Silicon Graphics, Inc. (650) 933-4899 ----- FAQ and OpenGL Resources at: http://www.geocities.com/SiliconValley/Hills/9956/OpenGL -- Author: Dave Shreiner INET: shreiner@sgi.com Fat City Network Services -- (619) 538-5051 FAX: (619) 538-5051 San Diego, California -- Public Internet access / Mailing Lists