OpenGL fallback

One of my clients is using a slightly older machine and is hitting errors. My FFT view component uses openGL and on 32bit build hits an error “nvoglv32.dll is not desigined to run…” and on 64 bit build everything’s fine except the component doesn’t show.

What’s the best way for checking at run time and using software fallback. Is was under the impression this was done under the hood but clearly something funky monkey going on. Paying client so would like to sort instead of saying go buy a new machine :wink:

No nice/easy way for testing. we tried some flows check if opengl extensions available / etc but that was never reliable enough.

With nVidia though many times I’ve been able to resolve issue by:

  • updated driver.
  • on laptops with multiple GPUs you can try the other graphics card by right clicking your host and explicitly selecting a GPU.

We now have flags/settings file to allow turn OpenGL off if needed.

That was my next thought is just to have a toggle in the settings menu to use openGL context or not. Not the end of the world.

I am considering implementing a similar “use OpenGL” setting to one of my plugins, and I’m weighing up the risk/reward of turning OpenGL rendering on or off by default.

@ttg I notice that in one of your plugins that includes that option, OpenGL is disabled by default. And UVI Falcon does the same, I think.

Is that because OpenGL support is too patchy to enable an OpenGLContext by default? And the plugin would therefore break for too many users? i.e. it’s better to have a plugin that works, albeit with sub-par UI rendering, than one that doesn’t work at all.

I am concerned that “off by default” will give some users a negative first impression, and they won’t realise that they can turn OpenGL rendering on to improve performance.

There’s no simple answer. :slight_smile:

  • For some GUIs, OpenGL might not provide huge improvement. also, if you’re always going through JUCE renderer. first, it’ll be better to optimize (and profile) your painting before OpenGL which might just hide the problem.

  • The above was written 2 years ago. we have much less OpenGL support issues those days and I guess newer versions will set OpenGL to default (it is now in most of SR plug-ins).

Thanks so much for taking the time to reply (I feel bad for digging up an old thread).

I’ve done a lot of work optimising my paint routines (spectrum analyser and goniometer), and I think they’re fairly performant. After I implemented the spectrum analyser only one of my beta testers reported degraded performance, but I’d still like to offer the best possible experience for everyone.

It is reassuring to know that OpenGL support issues are not as common as they were a couple of years ago. I suppose that another positive of the passage of time is that CPUs have gotten more powerful too, so a native paint routine that might have lagged a couple of years ago is more likely to run smoothly in 2020.