The title says all. No one needs 'em, no one wants 'em. Why are they still there?
How could THOSE survive the introduction of the core-profile at all and why wasn’t DSA enforced rigorously?
It is way beyond time to do so. The whole concept of preferring to set state-variables instead of using stateless access was a poor decision.
Agreed.
+1
The obsolete functions should be deprecated in the next version of OpenGL 4.x, next version would be 4.6 because current version of OpenGL 4.x at time of writing is OpenGL 4.5.
Please Khronos, bring out an OpenGL 4.6 in the summer of 2015 where you clean up the API somewhat by deprecating obsolete functionality.
Deprecate non-DSA functions and non-bindless textures in the 4.6 release.
(And other stuff if useful to deprecate, clean up the API.)
Assuming an OpenGL 4.6 comes out in summer 2015, an OpenGL 4.7 where the functionality deprecated in OpenGL 4.6 is removed in OpenGL 4.7 would be a good cleanup for the API to finish with.
Even with the Next Gen OpenGL 5 in development. It stays important to clean up older API’s.
OpenGL 4.x will be used by a lot of applications for a long time.
I agree. They could be deprecated in 4.6 and removed in 5.0 (if they’re following any versioning standard, a major version is necessary for removed features). However, the one big sticking point is textures. If target is included in a DSA function then it’s a mostly useless tagalong to provide support for cube maps, and if target is not included in a DSA function then it makes the non-DSA alternative persist in being necessary in core. “glGetTextureParameteriv(cubeMapTexture, GL.TEXTURE_CUBE_MAP_POSITIVE_X, &cubeMapFaceTexture);” could provide us with an id that mostly acts as a texture, but is limited in various obvious ways. Then the whole non-DSA mess could be freely kicked to the curb.
The “Named” functions are incredibly unfortunate. I really think the functions they’re conflicting with could just be removed for 5.0, and then remove the “Named” part of the names of the DSA functions. If someone creates a context that doesn’t specifically identify which version of OpenGL they want, then they must be served a version before 5.0 where the old functions still exist. If they access the libraries directly, then they must be given the old functions. That should almost completely avoid breaking compatibility. It’s a hard change, but I think it’s the kind of step we need to make.
In the future, you may wish to look something up before making assumptions about it. ARB_DSA basically killed the cubemap face targets and buried them in a shallow grave where they belong. glGetTextureParameteriv for cubemaps gets the parameter for the first face, since all of the other faces will have the same parameters. Hence the buried in a shallow grave thing.
ARB_DSA treats cubemaps like 2D array textures with 6 layers. Which is how they should have been treated all along. DSA has no targets, nor does it need them for anything.
That’s a non-starter. OpenGL is ultimately defined by C, and there’s no function overloading in C. Remember:the compatibility profile will still exist, which must still support both the original and the new. And if your code works in the core profile code, then people will be very confused if it doesn’t work in compatibility too.
So how would GLEW work, exactly, since there would be two versions of various functions? Some non-standard #define? Not everyone wants to create headers that omit compatibility stuff. And not everyone should have to care; some people just want “download and go”.
In order to do what, exactly? Such a change would not make your code one iota faster. It would not make it any more safe. It would not improve its debug-ability in the slightest. At best, it makes the code more readable. And even that’s arguable.