We're using an OpenGLContext attached to our main Component to enable rendering with OpenGL, which happens to be faster than the normal rendering backend.
However, in Windows machines with "Intel Graphics G41 Express" GPUs, features used by JUCE's OpenGL rendering are not available and the rendering becomes a black screen.
It would be useful to be able to tell if the GPU/driver supports what JUCE rendering requires and only attaching an OpenGLContext to the component if it does. Is there a way to do it? Any advice?
I thought someone from Intel posted here a while back to say this was a driver bug and the latest version fixed it?
We've had reports from some older cards not handling our opengl correctly including ATI's (AMD...).
I've saw the post by Intel and checked drivers. for this specific card for example there are no updates since 2012...
After we attach our component we can do some checks if extensions/shader init.
But once I've tried to detach it simply won't render the entire component by software...
Just to add an update,
To make sure this is related to JUCE OpenGL rendering of Components I've compiled JuceDemoPlugin with adding the following:
It produces BLACK view instead of plug-in...
(We've also tried TopLevelWindows for both the demo and our plugin...)
I've notice this thread talks about Intel Series 4 and there is sometime it is fixed:
I'll try to look into older commits to see if it got broken in the way or isn't related to what I'm seeing.
We've also tried running JUCE Demo on this machine.
- JUCE Demo in debug raises assertions for :
jassert (context.extensions.glActiveTexture != nullptr);
Release version can be more graceful (at least for OpenGL 2D). once clicked you'll get empty black view.
OpenGL however crashes on both debug/release.
caused when trying to createShader:
bool OpenGLShaderProgram::addShader (const String& code, GLenum type)
GLuint shaderID = context.extensions.glCreateShader (type);
This all definitely sounds like that Intel driver issue...
The biggest issue is we can't detach from OpenGL thread which is the only point where we can detect if GPU is unsupported.
I've tried repaint() but it is never called.
However, when we use JUCE's asynchronous ChangeListener,ChangeBroadcaster we were able to async call our component and detach within its thread.
I have just seen a page about OpenGL there, it might help to develop code which detects the availability of OpenGL features in JUCE :
That's how this software works : http://www.realtech-vr.com/glview/
As a side note, I have a computer on Windows XP with Toshiba+Intel drivers for the video card, and until I found a trick to get the last drivers from Intel (2012 too) and install them, I wasn't able to use OpenGL 2+ with JUCE
Bumping this, as we’ve gotten a lot of angry emails after releasing a free plug-in.
Has anyone come up with a good solution for this?
I would suggest creating an offscreen OpenGL context yourself and do some OpenGL support tests. After running these tests you can decide wether or not to attach your JUCE OpenGL renderer. Would be nice if JUCE could offer a mechanism for this though.
We ended up for project using JUCE purely (so OpenGL is just a switch) to add settings or flags to be used. so customer support would simply allow us to enable/disable OpenGL.
Still hope JUCE will provide a proper mechanism to handle this without users sending us “help!!! plug-in crashes when I open it!”
Thanks! What sort of diagnostics would you run?
The primary issue is that these old chipsets “support” OpenGL but provide a black screen when attempting to render.
For many customers, updating their drivers will fix the issue (mainly the Intel bug, but I’ve seen it pop up on a few AMD chipsets). However, many other users have old computers for which maintained drivers are no longer available.