OpenGL state. Who owns it?

Is there a single container storing the state info (glColor(), glBlendFunc(), glEnable(), etc…)?
Or do FBOs own their own state info? (separate from the screen’s state info)

No, FBOs don’t have their own state.
There was an old extension called p-buffer. You would create a context and a GL context and the p-buffer would have its own state. It was a bit of work to keep the states the same in the p-buffer and your main window, so FBO got invented.

Ok, thanks!

No, FBOs don’t have their own state.

Yes they do. They don’t have their own context, but there is state that is stored in FBOs besides what images are attached. glDrawBuffers, glReadBuffer, and a couple of other functions change framebuffer object state.

Really? Jeeze. It gets complicated.
I already knew that some state things get associated with the currently selected texture. Like the setting for linear vs nearest sampling and other raster-related things.

The documentation hasn’t been very clear on these things. The description for any given OpenGL function tends to focus on it’s parameters and return value. Doesn’t talk too much about how everything fits together and who owns what.

Unless there is some overview documentation that I missed. Something that broke down the functions and values and lists which are owned by a texture, which are owned by a FBO and which are owned by a context.

For example, who owns the values associated with these?


The reason I ask about this is: I am using an FBO as a mouse hit-test map.
When I draw geometry to the main screen, it gets drawn with antialised lines and antialiased triangles (via multisampleing).
But I my hit-test FBO needs to be aliased. Since each piece of geometry also gets drawn to it. Using a color that needs to be precise; since the color is used to lookup the object under the mouse later.
Antialiasing would result in color shades that I don’t want.

So, if there are a set of states that I need when I draw to the FBO, I need to know if I have to reset them every time, or if they will be associated with the FBO, while different state values are associated with the screen.

For example, the FBO would want some stuff like this:


While the screen would want the opposite.

The new 4.3 spec has an “Objects and the Object Model” chapter, but still describes the overall data flow through the pipeline, and leaves you to reference the State Tables appendix to figure out where the state really is.

It would be nice if there was a graph of the object hierarchy so you could see all of the state and the relationships between objects, in a single (large, like wall-sized) picture.