No, the OpenGL API is a mess. It's not because it's an API to do a complicated task but merely because of it's 1990's legacy. Just compare the OpenGL API to the

No, the OpenGL API is a mess. It's not because it's an API to do a complicated task but merely because of it's 1990's legacy. Just compare the OpenGL API to the Direct3D API and you should see a clear difference. The best (or worst) example of this is the OpenGL context, which is basically a global (actually: thread local) variable that tells which GL context and window should be drawn to. This context then stores a bunch of other global state, such as texture bindings. The API was (probably) designed like this because in the early 1990's it was actually a major optimization to avoid pushing parameters to the stack when calling functions several times a frame. Many graphics API's of that era did the same thing. Also there usually was only one screen with one fullscreen "window", so why not make the "display" a global variable? Now 20 years later we are stuck with this shit because it became an industry standard. OpenGL is a pain in the ass, not only for programmers but the implementors of the API. For example, take a look at OpenGL "texture completeness" rules (textures must have consistent mipmap levels, etc). Direct3D does not have an equivalent, because the API is designed so that all textures are always complete. Unfortunately we seem to be stuck with OpenGL for a while. There's not much interest for redesigning the API and as far as I can tell (I'm a Khronos member), no ongoing effort to do so. Direct3D is a much better API but unfortunately it supports a very limited number of platforms (none of which I actually like to use).