> Can you provide a reference for this?
The last OpenGL release 4.6 was in 2017... I think that speaks for itself ;)
And at least on macOS, OpenGL is officially deprecated, stuck at 4.1 and is also quickly rotting (despite running on top of Metal now - but I don't think anybody at Apple is doing serious maintenance work on their OpenGL implementation).
That's not "OpenGL is officially deprecated".
In the end, if nobody is maintaining the OpenGL standard, implementations and tooling it doesn't matter much whether it is officially deprecated or just abandondend.
.. but people ARE maintaining the implementations and tooling even if the spec might not be getting new features aside from extensions. There's a difference.
Look at Mesa release notes for example, there's a steady stream of driver feature work and bugfixes for GL: https://docs.mesa3d.org/relnotes/25.2.0.html (search for "gl_")
A slow moving graphics API is a good thing for many uses.
People are writing new OpenGL code all the time. See eg HN story sumbmissions: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
> A slow moving graphics API is a good thing for many uses.
It's not slow moving. It's completely frozen. The Mesa guys are the only ones actually fixing bugs and improving implementations, but the spec is completely frozen and unmaintained. Apple, Microsoft and Google don't really care if OpenGL works well on their platforms.
> the spec is completely frozen and unmaintained.
but, literally this article is about something new that was added to the OpenGL spec
Well, not really to the OpenGL spec itself. It's about a new OpenGL extension being added to the extension registry. Vendors may implement it if they wish. AFAIK the core OpenGL spec hasn't been updated in years, so even though new extensions keep getting developed by vendors, the official baseline hasn't moved.
I suppose the same is true of Direct3D 11, though. Only the Direct3D 12 spec has been updated in years from what I can tell. (I'm not a graphics programmer.)
A main reason to do new OpenGL releases was to roll developed extensions to required features of a new OpenGL version to give application programmers a cohesive target platform. The pace of API extensions has slowed down enough that it's not going to be a problem for a while.
> but I don't think anybody at Apple is doing serious maintenance work on their OpenGL implementation
In other words nothing changed. The OpengGL standard had been well past 4.1 for years when Apple released Metal. People working with various 3D tools had to disable system integrity checks to install working drivers from NVIDIA to replace whatever Apple shipped by default.
I've never been able to successfully create a GL context > version 2.1, or invoke the GLSL compiler.
As a sidenote, I've very much enjoyed your blog, and developed a similar handle system as yours around the same time. Mine uses 32 bits though - 15 for index, 1 for misc stuff, 8 for random key, and 8 for object type :^)
Recent versions of macOS will provide either an OpenGL 2.1 context or OpenGL 4.1 context, depending on how you request the context. You have to request a 3.2+ core profile, and not use X11 or the glX* functions.
From macOS 10.7 to 10.9, you'd get an OpenGL 3.2 context. As OpenGL 4.1 is backward compatible to OpenGL 3.2, it's fine that the same code gets OpenGL 4.1 now.
Basically, macOS will provide an "old" API to programs that need it, which is fixed at 2.1, and a "modern" API to programs that know how to ask for it, which has settled at 4.1 and is unlikely to change.
OpenGL 4.1 is harmonised with OpenGL ES 2.0. Almost the same rendering model, features, extensions, etc. On iOS, iPadOS etc you can use OpenGL ES 2.0, and no version of OpenGL (non-ES), so my guess is that's why macOS settled on OpenGL 4.1. Both platforms offer the same OpenGL rendering features, but through slightly different APIs.
But if you request 4.1 over GLX (which uses X11/Xorg/XQuartz), the X11 code only supports OpenGL 2.1. For example, if you're porting some Linux code or other GLX examples over.
Unfortunately, the GLX limitation is probably just due to the Xorg-based XQuartz being open source but only minimally maintained since before OpenGL 3.2 was added to macOS. XQuartz uses Xorg and Mesa, which have all the bindings for 4.1, but some of them are not quite wired up.