[simias]

I'm far from an expert in the field but what annoyed me deeply with OpenGL was the implicit global state and, in particular, the fact that it's very difficult and error-prone to make applications that interact with OpenGL from multiple threads.

In a way I find OpenGL too complicated sometimes, some of its abstractions don't really make a whole lot of sense on modern hardware. Having a lower level API can make some code simpler to write, at least in theory. When I use OpenGL I often find myself thinking "I sure hope the driver will manage to understand what I'm trying to do and not end up doing something silly".

Note that my exposure to OpenGL comes mainly from console emulators though, and that's obviously very biased since emulators need to mimic very quirky behaviors of the original hardware, and that often results and very un-idiomatic GL code.

[moonchild]

> implicit global state

In 4.x they added DSA[1], which lets you avoid the global state a lot of the time. There's still some, but much less.

I do agree, though, that opengl is somewhat a mess, and vulkan really overwhelming.

1. https://www.khronos.org/opengl/wiki/Direct_State_Access

[pcwalton]

> in particular, the fact that it's very difficult and error-prone to make applications that interact with OpenGL from multiple threads.

These days I rarely ever bother with threaded OpenGL, and I stick to one context per thread, using OS surface sharing primitives (DXGI, IOSurface, etc.) to communicate.

[pmarreck]

> the implicit global state and, in particular, the fact that it's very difficult and error-prone to make applications that interact with OpenGL from multiple threads

These things are obviously related.

From my work in OO langs, I believe it is possible to wrap OO code in functional code to some degree without rewriting, assuming that global references can be intercepted and resolved to local ones somehow, and that the state reference that encompasses all the globals is an immutable data struct