FR: Wrangle a comprehensive set of OpenGL functions & macros

General JUCE discussion
1

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.

Some example functions that should be included:

2

but OpenGL is being deprecated… so why bother adding features to a DOA spec?

3

What are you on about? No, it’s really not DOA by any stretch of the imagination! And it’s going to be around for another long while.

Apple did mention deprecating it, but that does not mean it’s suddenly vapourware for all platforms (you know, not Apple platforms).

Also, people won’t suddenly migrate to Vulkan, which many drivers and hardware don’t support. It’s also even more complex to wrap your head around and integrate.

OpenGL is mainstay for all systems for another long time.

7 Likes
4

+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
#if JUCE_WINDOWS
#define GL_BGRA                     0x80E1
#define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367
#define GL_TEXTURE_MAX_LEVEL		0x813D
#endif

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.

4 Likes
5

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.
4 Likes
6

Nice change! All the openGLContext references are gone. Looks much cleaner now.

I know you’re probably busy, but can you give your opinion on this matter?

Looking at a window library like GLFW it seems they all use wglCreateContextAttribsARB to create the GL context on Windows. Why is it that juce_OpenGL_win32.h only uses wglCreateContext ?

Here the GLFW implementation using it:
https://github.com/glfw/glfw/blob/master/src/wgl_context.c

Also more information in this recent post here

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?

7

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.

1 Like
8

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.

1 Like
9

Thanks for this!

The only thing I can report is that it appears to work the same as before in my apps.

1 Like
10

I like that more than “breaks catastrophically”! In that case, I’ll look to get this merged in the next few days. Thanks for testing this out!

2 Likes
11

This change is now on develop. I’m closing this thread so that you can have your votes back. If you run into any issues with this change, please start a new thread.

4 Likes
12