for glPushAttrib: “Not all values for GL state can be saved on the attribute stack. For example, render mode state, and select and feedback state cannot be saved.”
for glPushClientAttrib: “Not all values for GL client state can be saved on the attribute stack. For example, select and feedback state cannot be saved.”
Maybe it would be better if definition of plugin API contained description of state which plugin can expect on beginning and into which each plugin must return OpenGL before it ends.
Not all parts of that state must be exactly defined. For example if state specifies that blending is disabled, state of blending functions can be undefined.
As Komat and Zbuffer pointed out that this might cause problems, it is also inefficient to a great extent! One thing that you can do is to implement some sort of state block mechanism (like you have in Direct3D) where state changes are saved “on demand”. That way you can have more control and you will face fewer problems and your code will most probably be more efficient (depending on your implementation, ofcourse). e.g. you can choose not to save common states or states that don’t effect your rendering. I have implemented such a mechanism for OpenGL and it works great and hardly took me a couple of hours to get it up and running once the design was complete.
what about having one different RC for each plugin? The RC change is an expensive operation, but if you wont change between dozens of plugins in each frame the problem is minimal. Also you cal use wglShareLists if you need it.
some Pseudocode:
WRT speed of gl query commands,
in my app (for debugging purposes) i query all the states with glGet…() etc roughly 300 per frame, running at 100fps == ~30,000 get commands a second.
the thing is if i disable that it makes no difference at all.
WRT speed of gl query commands,
in my app (for debugging purposes) i query all the states with glGet…() etc roughly 300 per frame, running at 100fps == ~30,000 get commands a second.
the thing is if i disable that it makes no difference at all.
Wow! What if you someone runs it on hw X and gets 10 FPS because of those glGet?
In general it’s better not to use them and not to use glPushAttrib and glPushClientAttrs
true, but this is only for debugging purposes, eg seeing if my interpretation of gl is the same as the actual figures or somehow ive started to use the fixed pipeline etc.
i said this to counter the oft-quoted remark that gl query commands will kill performance.
though in saying that obviously the fastest command is the one not called.
