Without getting into details, the worst part of the API is the inherent statefulness of it. To exaggerate a little, OpenGL is essentially a very complicated glo

Without getting into details, the worst part of the API is the inherent statefulness of it. To exaggerate a little, OpenGL is essentially a very complicated global state variable where state changes have side effects. (actually it's thread local but global scope in most programming languages - but this only makes matters worse) If you look back (or remember) graphics APIs from the 1980s and 1990s (e.g. the BGL library that shipped with Borland compilers), this was a common idiom. Rather than saying drawLine(100, 100, 200, 250, RED); drawLine(200, 250, 300, 300, RED); You did setColor(RED); movePen(100, 100); lineTo(200, 250); lineTo(300, 300); The idea behind this was to minimize the number of parameters passed to function calls, because they had to be pushed to the stack and then read back. This was a major source of performance overhead back then. So basically OpenGL is modelled after a performance optimization that was relevant some 30 years ago. These days it's actually hurting performance and adding unnecessary complexity. Premature optimization of the worst kind. You could do a little comparison on how Direct3D 10.1 and newer work. The API is simpler, lot less stateful and you get a better idea what will actually happen. If I had a choice, I would use D3D, but it doesn't run on the platforms I care about.