MacOS OpenGL: Context stays black

MacOSX and iOS
1

I’ve recently started to port my plugin to MacOS. Everything renders fine, except any stuff drawn manually with OpenGL stays black. I haven’t been able to find a solution, so I decided to go back to the tutorial which spawned all my progress when I started:

And behold, it seems even the simple tutorial window will stay black.

I’ve also noticed that I absolutely need to additionally set

m_openGL_context.setOpenGLVersionRequired(juce::OpenGLContext::OpenGLVersion::openGL3_2);

and adjust shaders to new openGL syntax in order not to get shader compile errors. (Btw. why does the OpenGLVersion enum have only two entries?)

Does anybody have any idea what could be wrong here? I’d be happy to get some insights on how to debug the OpenGL stuff to begin with.

Edit: The OpenGL demos in the JUCE examples both seem to be working fine.

Edit2: Here’s some information about the build machine:

=== OpenGL/GPU Information ===
Vendor: Intel Inc.
Renderer: Intel(R) Iris(TM) Plus Graphics 640
OpenGL Version: 4.1 INTEL-12.10.30
OpenGL Major: 4
OpenGL Minor: 1
OpenGL Shading Language Version: 4.10
2

Debugging issues like the black screen you’re seeing is a lot easier if you enable the debug callback on the context. Take a look at the example at the bottom of this page: Debug Output - OpenGL Wiki

You can also stick a breakpoint inside the MessageCallback to find out which calls are causing problems.

3

Thanks for your answer! I managed to get the debug callback working on Windows and Linux, but on Mac the function call to glDebugMessageCallback( MessageCallback, 0 ); causes a

EXC_BAD_ACCESS (code=1, address=0x0)

It is my understanding that this happens when no context is currently active, which is weird, because I call it inside newOpenGLContextCreated().

However I noticed that even just enabling glEnable( GL_DEBUG_OUTPUT ) without the Debug callback will enable the error handling via JUCE_CHECK_OPENGL_ERROR. So I littered my entire code base with this debug macro, and it throws immediately on the first call. Even this code:

void OpenGLComponent::newOpenGLContextCreated()
{
  glEnable( GL_DEBUG_OUTPUT );
  JUCE_CHECK_OPENGL_ERROR

  ...
}

will trigger the debug macro with the message:

***** GL_INVALID_ENUM

So a broken function call is already made before my code even starts?

I’m still at a complete loss as to what’s happening. Any help appreciated, thanks.

1 Like
4

Did it produce any debug output on those platforms? If so, it’s worth working out exactly what’s broken on those platforms before moving on to macOS. Depending on the problem, there’s a reasonable chance that the same issue is affecting macOS builds too, but it sounds like it will be much easier to debug on Windows/Linux.

Unfortunately glDebugMessageCallback is only supported on OpenGL contexts version 4.3 and higher. According to this page a 4.3 context is also required in order for glEnabled (GL_DEBUG_OUTPUT) to succeed. I think that the ‘invalid enum’ error is caused because the older context doesn’t understand the GL_DEBUG_OUTPUT enum.

Looking at your original post, I can see that your context is version 4.1, so it won’t have the new debugging feature. Sorry, that was bad advice!

If you remove the initial call to glEnable (GL_DEBUG_OUTPUT) but keep all of the JUCE_CHECK_OPENGL_ERROR calls, are any other errors produced?

5

Both Linux and Windows just spam buffer binds like this:

GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 33 (bound to GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 34 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.

Which I think is the desired result.

This is precisely what’s happening! I thought the glEnable() call enabled the logging, when in reality it only triggered an error itself :smile:. Good thinking on your part.

As mentioned before, the OpenGL demos in the DemoRunner seem both to work fine on my Mac machine. Perhaps it is time to ditch the tutorial and look how things are done in the DemoRunner. Hopefully I can work towards a solution from that point. I spent half a year building on top of the tutorial, but I guess the lesson to be learned is to test on all platforms early.

Once again thanks for your answers, very much appreciated!

6

I managed to find a solution by recreating everything on top of the rotating teapot OpenGLDemo. I’ve taken the opportunity to do a major code cleanup. Therefore, I can’t really compare what the problem was in the first place, and why even the simple tutorial from the OP would not work. As far as I can tell, both are built on the same foundation.

If anyone finds themselves in the same situation (after following the tutorial) I would advise to use the JUCE demo as a basis.