# MacOS OpenGL: Context stays black **URL:** \ **Category:** MacOSX and iOS\ **Created:** [February 16, 2022, 9:19pm UTC](https://forum.juce.com/t/macos-opengl-context-stays-black/50220 "2022-02-16T21:19:52Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![TheWaveWarden](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/thewavewarden/32/13708_2.png) [@TheWaveWarden](https://forum.juce.com/u/TheWaveWarden)\ **Post date:** [February 16, 2022, 9:19pm UTC](https://forum.juce.com/t/macos-opengl-context-stays-black/50220/1 "2022-02-16T21:19:52Z")
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: > **[Using OpenGL for 2D graphics in a JUCE plug-in.](https://medium.com/@Im_Jimmi/using-opengl-for-2d-graphics-in-a-juce-plug-in-24aa82f634ff)** > > A crash course in creating hardware-accelerated graphics in a JUCE plug-in using the OpenGL module. And behold, it seems even the simple tutorial window will stay black. I’ve also noticed that I absolutely need to additionally set ```auto 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: ```auto === 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 ``` ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [February 16, 2022, 10:34pm UTC](https://forum.juce.com/t/macos-opengl-context-stays-black/50220/2 "2022-02-16T22:34:00Z")
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](https://www.khronos.org/opengl/wiki/Debug_Output) You can also stick a breakpoint inside the `MessageCallback` to find out which calls are causing problems. ---
**Author:** ![TheWaveWarden](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/thewavewarden/32/13708_2.png) [@TheWaveWarden](https://forum.juce.com/u/TheWaveWarden)\ **Post date:** [February 18, 2022, 2:30pm UTC](https://forum.juce.com/t/macos-opengl-context-stays-black/50220/3 "2022-02-18T14:30:59Z")
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 ```auto 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: ```auto void OpenGLComponent::newOpenGLContextCreated() { glEnable( GL_DEBUG_OUTPUT ); JUCE_CHECK_OPENGL_ERROR ... } ``` will trigger the debug macro with the message: ```auto ***** 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. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [February 18, 2022, 2:41pm UTC](https://forum.juce.com/t/macos-opengl-context-stays-black/50220/4 "2022-02-18T14:41:48Z")
> [@TheWaveWarden](#): > > I managed to get the debug callback working on Windows and Linux 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](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glEnable.xhtml) 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? ---
**Author:** ![TheWaveWarden](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/thewavewarden/32/13708_2.png) [@TheWaveWarden](https://forum.juce.com/u/TheWaveWarden)\ **Post date:** [February 18, 2022, 3:35pm UTC](https://forum.juce.com/t/macos-opengl-context-stays-black/50220/5 "2022-02-18T15:35:01Z")
> [@reuk](#): > > Did it produce any debug output on those platforms? Both Linux and Windows just spam buffer binds like this: ```auto 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. > [@reuk](#): > > I think that the ‘invalid enum’ error is caused because the older context doesn’t understand the `GL_DEBUG_OUTPUT` enum. This is precisely what’s happening! I thought the `glEnable()` call enabled the logging, when in reality it only triggered an error itself 😄. 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! ---
**Author:** ![TheWaveWarden](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/thewavewarden/32/13708_2.png) [@TheWaveWarden](https://forum.juce.com/u/TheWaveWarden)\ **Post date:** [February 21, 2022, 10:00pm UTC](https://forum.juce.com/t/macos-opengl-context-stays-black/50220/6 "2022-02-21T22:00:19Z")
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.