Quote:Original post by neebee
I want to know how exactly opengl saves the states and etc.

I mean when you call glBegin or something like this it sets some state variable. where are these state variables defined? not in gl.h I suppose? because these variables are global and no matter which scope of your application you call them, it sets them.

Each context has its own state, so it's not completely horrible. A lot of it can be read by calling functions such as glGetIntegerv, glGetDoublev, etc.

This is a very complex topic. In short, the state is tracked by the OpenGL driver.

OpenGL drivers are typically separated into a "frontend" or "state tracker", which translates incoming OpenGL calls into some internal representation; and a "backend" or "hardware driver", which translates that internal representation into a command stream that can be executed by the GPU.

Of course, things are much more complex than that. OpenGL drivers must emulate features in software if the hardware does not support them ("software fallback"). Before your OpenGL commands reach the drivers, they typically travel through an OS-provided library (opengl32.dll, libGL.so, etc) which must choose the correct driver to dispatch them to.

If you wish to learn more about the dirty details, there's no better source than mesa3d.org. This is an open-source implementation of OpenGL, which contains both the state tracker and a large number of hardware *and* software drivers. It forms the backbone of 3d graphics on Linux and a number of other operating systems.

Start with the dispatching mechanism and head over to mesa3d.org for more documentation and the actual source code.

Moved to OpenGL.

Quote:Original post by neebee
en passant, this kind of a programming approach for a library is outdated now as far as I can understand?

is there a performance benefit for this or should I stick with C++ classes for library implementations?

Many (most) OpenGL drivers are implemented in C++, with only the public interface being defined in C. The reason? Every language can consume C interfaces in some way. Nothing can consume C++ interfaces, at least not in any cross-platform way (since C++ does not have a well-defined ABI).

In other words, as long as your library exposes a C API, it doesn't really matter what language it is actually implemented in.