OpenGL Version Support Change?

Did something change recently (within the past two months) with regards to OpenGL support on Windows?

I have a user with a relatively old Windows machine which says when using OpenGL, the screen is simply black for him now.

I know there was a breaking change with respect to the GLEW function loading but will this have broken existing versions? I don’t think we do any special OGL stuff, just change the top level renderer.


Hmm, could be. Wouldn’t that mean that a larger texture is just created and only a subview of it displayed on screen though?

I removed some of the JUCE_OPENGL3 checks recently, so perhaps that could be causing issues on some platforms which don’t support OpenGL 3 (although I did test on Linux with GL 2.1 recently and that seemed fine). I’m currently trying to find a way to force my Windows install to use an older version of OpenGL to test out this theory.

Nothing significant has changed that should affect you this way.

Have you received the user’s GPU and OpenGL driver versions?

A black screen is a common result when using Intel drivers, especially old ones; they don’t properly support GL at all.

We have been using this structure to auto-detect old systems and to auto-detach the juce::OpenGLContext in such an event: squarepine_core/HighPerformanceRendererConfigurator.cpp at main · SquarePine/squarepine_core · GitHub


I’ve asked for some more OpenGL details from the user.

I haven’t been able to replicate this either, even with a fairly old EliteBook I’ve got.

I might have to add in a check like you linked to disable GL if the drivers don’t support it, that would be ok for new customers but it’s odd for people who it was working for if it just suddenly stops working with an update (and we don’t have any obvious rationale).

Unfortunately I’ve not had much success reproducing this. On a VirtualBox VM with no OpenGL support, the DemoRunner displays a black screen after enabling the OpenGL renderer both with JUCE 6.0.5 and with current develop. I couldn’t find a way to create an older OpenGL context in my VMWare Fusion VM, so I haven’t been able to test with an old GL context on Windows.

I got some more details back from the tester. Apparently the OpenGL version is 1.108 using a “Mobil Intel 965 Express Chipset Family”.

I’m guessing JUCE just doesn’t support versions that old? Although I would have thought that would never work… Didn’t shaders appear in OpenGL 2?

I think we might just have to put this down to his system being too old. I’ll see how many more users this affects as I push the build out to the public. :crossed_fingers:

1 Like

There’s no way this ever ran anything OpenGL related from JUCE since that device is from 2007. I would suspect it’s barely getting by in plainly rendering your app!

I’ve added a small change which should reinstate some behaviour which may have got broken during the function-loading update:

I’m not sure whether this is relevant to your user on the 965 chipset, as it seems like texture copying (and possibly other bits and pieces?) would be broken on a card which doesn’t support OpenGL 2, but thought I’d let you know just in case.

Ok thanks. I’ve mentioned to the tester we don’t support chipsets that old for OpenGL but I’ll let him know this might have made a difference. Cheers!

(removed commits) - need to better bisect this but I see changes of profiles on OpenGL_win32.h

On my machines I’ve noticed it’s now using a newer (latest OpenGL context).
Meaning any older glsl/opengl pre 3.x can easily fail resulting black screen.

@dave96 - In our case I’m now able to ‘reproduce’ the black screen on macOS by explicitly enforcing setOpenGLVersionRequired (juce::OpenGLContext::OpenGLVersion::openGL3_2). without this I get GLSL #110.
After this I get GLSL #150 and any removed pre-3 API breaks also on a mac.

Trying to figure out if there’s a way to enforce older opengl version on Windows.

1 Like

It looks like context-creation changed a few times on Windows. For a while JUCE didn’t take the requested OpenGL version into account at all. Then, it was updated to allow creating a 3.3 core profile when openGL3_2 was requested. This was quickly adjusted to return a 3.2 core profile to match the behaviour on macOS. Shortly after that, it was updated again to return a 3.2 compatibility profile.

I’m not convinced that the latest change is correct. If we want to provide the same behaviour on macOS and Windows, then we should be creating a 3.2 core profile on Windows too. I’ll need to test a bit to find out if there are other workarounds for the issues that were mentioned in this thread:


I’ve attempted to fix the issue here:

Now, requesting an OpenGL 3.2 context will always return a Core profile rather than a Compatibility profile.

1 Like