which one is better and which one is faster?
you don’t know if GL_DEPTH_TEST is enabled before and after the // …
glPushAttrib( GL_DEPTH_BUFFER_BIT );
if ( glIsEnabled( GL_DEPTH_TEST ) == TRUE )
if ( glIsEnabled( GL_DEPTH_TEST ) == FALSE )
As for speed:
Unless you make one of these sets of calls thousands of times times, it may not be measureable.
As for which is better, I would prefer to use 1.
I use push atribute when I’m pushing many attributes.
Hope this helps.
#define disabled 0
#define enabled 1
int depthbuffer = disabled;
if(depthbuffer == disabled)
depthbuffer = enabled;
if(depthbuffer == enabled)
depthbuffer = disabled;
This is what you should do. Mirror the state you need in local variables so you don’t have to do rendurant state changed, pushing/popping states, or query states.
Anyways, worrying about things like this is the last thing you should do. Trust me, if you worry about it too much, you will never even get your projects half done.
IF you want extreme speed make sure everything you render is red. cos Red comes 1st in RGBA, so it pipes out to the hardware faster.
pushing and poping attributes is slow
bob, it is up to the opengl implementation, to check, whether a state is enable or not (if changing a state is in fact slower than checking).
i would do it the 1st way. as lobstah stated, pushing and poping do only make sense, if there are many states to switch.
method 4 (bobs) is quickest
all the other 3 are far slower
Tolga, yes the implementation can check for redundant state changes internally, but most implementations don’t. It’s considered bad style to do redundant state changes and relying on the driver to sort it out. All this is covered in the FAQ btw.
Well, it’s a matter of opinion. I consider it bad design when a library’s user is forced to keep track of the library’s state in order to avoid making redundant state changes.
[This message has been edited by Jambolo (edited 01-13-2002).]
Thanks for the input Jambolo, of course it’s up to the implementor to do this. The problem is that to do the test slows down a raw glEnable glDisable when the application KNOWS what it is doing.
What you are saying Jambolo is that someone doing
should see a minimal performance impact at the expense of someone doing
That’s an option for implementors, but better programmers may object in principal to slowing down their single glDisable(GL_DEPTH_TEST); call.
OpenGL has nothing to say about which choice the implementor makes, and with some implementations it may have almost no impact either way.