DBG call in openGL

1

in modules\juce_opengl\opengl\juce_OpenGLShaderProgram.cpp

in line 68 there’s this:
GLuint shaderID = context.extensions.glCreateShader (type);

and it creates the following output into the console:
OpenGL DBG message: Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
OpenGL DBG message: Buffer detailed info: Buffer object 2 (bound to GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.

I’m still pretty new to openGL, but I’d appreciate it to not spam the console without giving a warning or error, since that is usually where I debug things. Can it be turned off? If no: Can you improve the code so that it doesn’t DBG into the console anymore?

2

the only way is in juce_OpenGLContext.cpp initialiseOnThread() ignore that warning. I think that all notification type GL_DEBUG_SEVERITY_NOTIFICATION could be ignored

3

I finally found a solution that doesn’t need to modify that function or create a custom debug callback. It is possible to directly disable messages with OpenGL, in this case specifying the source, type and severity

gl::glDebugMessageControl(gl::GL_DEBUG_SOURCE_API, gl::GL_DEBUG_TYPE_OTHER, gl::GL_DEBUG_SEVERITY_NOTIFICATION, 0, 0, gl::GL_FALSE );

It seems that it is possible to disable specific messages
https://registry.khronos.org/OpenGL-Refpages/gl4/html/glDebugMessageControl.xhtml

by the way, in the callback of Juce’s module it seems that there is an error, the first parameter is source, not type

1 Like
4

Updated to the latest JUCE and got this error this morning.

Would be happy to suppress and move on, except the UI is also now extremely slow.

Maybe something changed in the GL code that is causing problems on Windows?
I tried breaking code execution to see if it’s stuck in a loop, but it’s not.
Any interaction with the UI will happen (Eventually, as in 5 seconds late).

Setting all subcomponents invisible doesn’t help, so it’s not something that a particular element is doing, even an empty DocumentWindow still runs way too slowly.

No issues on mac, just windows.

5

Is it slow in both debug and release mode?

6

Yes, so it’s not just the error message printing.

Even with all components invisible, it is doing a bunch of UI/state refresh things … so it might still be related to something more specific. If I just use a generic test editor component I have laying around the issue gets much better.

7

Are you able to bisect to find out which JUCE commit introduced the problem?

9

On another note - how do I use the openGL command above (gl::glDebugMessageControl)?

If I paste that line just after my attachToComponent() line (or anywhere else I’ve tried) it crashes with access exception.

I would really like to disable this constant stream of debug outputs from GL.

10

Yup, it was my issue.

11

in my case the problem was solved by just putting this line at the beginning of newOpenGLContextCreated()

glDisable(GL_DEBUG_OUTPUT);

but disabling outputs manually like that seems like it could introduce other problems since debug messages are there for a reason i guess. i’m still an openGL noob though so idk

2 Likes
12

I changed to creating the component as OpenGLAppComponent, because I had problems and it works better for me. if you want you can test it very fast, just derive the component from that class and do the mandatory, which is override initialise(), shutdown() and render(), and in the destructor add shutdownOpenGL();

13

Ah, great to know.
I’ll give that a look.