This FR requests adding a more comprehensive set of functions and macros to the existing lists in the GL wrapping logic.
A variety of loading libraries exist already (GLEW and GL3W spring to mind). The thing is, if JUCE wants to go into a path that works and looks nice with the framework, then it really should go the whole way - preferably with some tool that automatically generates the lists of funcs and macros.
+1 for this.
for my current project, I had to add these macros as they weren’t defined by JUCE:
// these definitions aren't a part of juce::MissingOpenGLDefinitions
#define GL_BGRA 0x80E1
#define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367
#define GL_TEXTURE_MAX_LEVEL 0x813D
As a side note, it’s kind of strange that on macOS, you can do juce::OpenGLExtensionFunctions::glSomething, while on Windows you have to obtain an instance of OpenGLExtensionFunctions. I suggest making these functions non-static on macOS as well, so that devs like me who primarily code on macOS don’t get caught by surprise when their code that even uses OpenGLExtensionFunctions for supposed Windows compatibility breaks when switching to Windows.
Thanks for this FR. I’ve had a go at implementing this here:
Note that is this currently not on develop. Given the scope of this change, it felt safer to put it on a feature branch so that it can get a bit of testing before merging it into develop. You can try out this change by checking out generated-opengl-headers.
I’d really appreciate any feedback you can give about this change, as we don’t have a lot of OpenGL-dependent code to test with here.
Things that have changed:
All GL symbols are in juce::gl. You can either manually prefix all symbols, or you can use using namespace juce::gl to make all GL symbols visible in a specific scope. We recommend doing this at the smallest viable scope, so definitely avoid adding this to headers.
The JUCE_OPENGL3 preprocessor definition no longer does anything.
I can’t find much information about what wgl actually does under the hood and what version it is and how it’s related to the GPU vendor drivers. And how it’s releated to the loaded GL functions and version. Could loading a newer wgl context with this extension improve the stability of GL on windows?
I don’t know the history here, but it looks like wglCreateContextAttribsARB was introduced at around the time of OpenGL 3. As far as I’m aware, JUCE’s OpenGL module predates OpenGL 3. I suspect the code started out using wglCreateContext, and there’s never been a reason to change it.
As I understand it, the purpose of WGL is to handle all the platform-specific details to do with creating and using GL contexts on Windows.
I’m not sure about stability, but wglCreateContextAttribsARB would allow us to be a bit more specific about the version and kind of context that gets created. It looks like we don’t currently respect the OpenGLVersion which is requested on Windows, so perhaps we should investigate adding support for that.
Interesting that you mention this. The unfortunate thing about this lack of version switching is that I’ve had to resort to manually defining JUCE_OPENGL3=1 for the last… many years… to get OpenGL 3+ to work on Windows. (Windows & OpenGL 3 fix)
The downside is that users with ancient hardware running this software end up with a blank screen (usually old on-board Intel GPU laptops, 2010 and older). So in order to get things drawing as normal (using the software renderer), I have to query the OpenGL version and conditionally remove the juce GL context from the top-level window.
Would be nice to have that version switcher in place as OpenGL 2.1 will probably be fine for most older systems/crappy machines.