#### Archived

This topic is now archived and is closed to further replies.

# OpenGL Managing OpenGL state

This topic is 6110 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

So, what''s the "right" way to manage OpenGL state? Meaning, if I have some routines, say for font rendering, etc that modify the OpenGL state (like the currently bound texture, etc), what is the "right" way to do it? Do I assume that the caller will reset any state on return of my function? Or do I try to save/restore the state on entry/exit of my function? I''m leaning towards the first one, letting the caller manage state, because I think I remember reading that "reading" state can sometimes be expensive, while "writing" state is relatively cheap. Comments? Suggestions? Thanks, -Brannon

##### Share on other sites
Lookup glPushAttrib and glPopAttrib. I basically use them like this:
  class Fish { public: inline static void BeginRender(void) { glPushAttrib(...); // Set Some States } inline static void EndRender(void) { glPopAttrib(); } void Render(void);};Fish Alpha, Beta;Fish::BeginRender(); Alpha.Render(); Beta.Render();Fish::EndRender();

That way I only have to push and pop once per batch of ''Fish'' I must render. Of course, this has its limits too, but it helps a lot .

[Resist Windows XP''s Invasive Production Activation Technology!]

##### Share on other sites
Yes, I''m aware of glPushAttrib/glPopAttrib. That is kind of what I was getting at... are those functions really expensive? Is it better to just document "hey, calling this function will modify these OpenGL states.. so reset them afterwards." ?

-Brannon

##### Share on other sites
I went across this problem a month ago i think , i was testing the drawing of a lot of tsingle textures , basically for my engine i''m using a sort of ''shader'' for each objects thatwraps every state used for rendering from the shade model down to the depth testing and i''ve found that glenable is very expensive, reading aorund the net i''ve discovered that each call to opengl state changes writes or read the hardware bits in the video board , so i''ve written a class the wraps the glenable command ( forcing inliling of course ) and before writing checks if the state is already set using a flag , this saves a lot of time exspecially if you have large walls of the same texture.just my 2 cents

1. 1
2. 2
frob
20
3. 3
4. 4
Rutin
18
5. 5
• ### Forum Statistics

• Total Topics
632555
• Total Posts
3007059

×