Site navigation

OpenGL initial state question (Windows)

Audio Plugins
#1

We have added the ability to turn on OpenGL support in our plugins, by including an OpenGLContext object in our main editor Component, and calling context.attachTo(*this) to turn it on. The user preference defaults to true (on). However, we have found that for some Windows users, something in their systems is causing the plugin window to show up as a blank window when this is turned on, and since the window does not draw, they cannot see where to click to turn the feature off. I do not know exactly what causes the window to show up as blank, so I don’t know any way to detect that it is (or will do so when the window opens). We’d like for this feature to default to true, but we can’t figure out a way to safely do that. Any ideas? Thanks!

(By the way, is it correct that all I have to do is call context.attachTo(*this), and all my drawing will use that context, including sub-components of the main editor?)

#2

Welcome to OpenGL! Gut feeling is that the user is set up with:

  • A ridiculously old and/or garbage driver
  • An Intel GPU
  • Or a combination of both (Intel is notoriously bad at making GPU drivers. NVIDIA is known to have a lax approach to shaders. AMD is known to have strict shader parsing.)

What you can do is check to see if the context fails to init or attach so you can fall-back to software rendering immediately.

I’ll make an edit to this post when I find you the steps on how to do just that - it’s not straightforward to figure out at all!

1 Like
#3

I was under the impression that it would automatically fall back to software rendering if the context failed to init or attach. Is that not the case? I do know that I cannot immediately ask isAttached() after calling attachTo(), because it does not actually attach until some point in time later, and then only if the Component is visible. Plus I’m not sure if it actually is failing to attach or init, or if it’s simply hung trying to show our rather large graphics.

#4

Yeah

Not exactly no. What happens is that the Attachment created underneath the OpenGLContext's hood doesn’t go away when it should, leaving you in a stuck state where nothing can be drawn.

1 Like
#5

@HowardAntares Try this out, and tweak it to your needs for your plugin. I’ve used this in several apps now (just internal tools and playing around, tested on several PCs) and it’s worked fairly consistently. I might have buggered up the code by pasting and shuffling things around so it might not build out of the gate.

The point of this code is to automatically delete the context if shit hits the fan.

HighPerformanceRendererWindow.zip (2.9 KB)

If you want to attempt OpenGL 3.x over the default 2.x, as it might improve performance or extend driver support range, you should try adding this to your AppConfig.h in the user code section:

   #if defined (_MSC_VER) || defined (__APPLE_CPP__) || defined (__APPLE_CC__) || defined (LINUX) || defined (__linux__)
    #undef JUCE_OPENGL3
    #define JUCE_OPENGL3 1
   #endif

The reason is that JUCE doesn’t actually go about this correctly at all because OpenGL is not about macros for configuration and initialisation - it’s about the driver providing the information you so need to gather the function pointers to go about your business.

2 Likes