Opengldemo in jucedemo: crash


#1

Hello,

trying out jucedemo on windows, and got an intermittent crash (unhandled exception) in the following function:
glDrawElements (GL_TRIANGLES, (numVertices * 3) / 2, GL_UNSIGNED_SHORT, 0);

JuceDemo.exe!juce::OpenGLRendering::StateHelpers::ShaderQuadQueue::draw() Line 1032 C++

(the crash is actually in the nvogl driver when glDrawElements get’s called. )
I managed to crash it pretty consistenly by switching back and forth between the opengl demo and other demo pages. (raising the numQuads just got it to crash faster)

I noticed the following line above it:
enum { numQuads = 64 }; // (had problems with my drivers segfaulting when these buffers are any larger)

I’ve seen crashes like that before.
Nothing seems wrong with the buffers or the shader, but the graphics driver crashes, on arrays that you’re not even using in your shader.

If you add a couple of glDisableClientState’s in the files juce_OpenGLHelpers.cpp, juce_OpenGLContext.cpp and juce_OpenGLFrameBuffer.cpp then it would help.
In short, if I match all
glEnableClientState (GL_VERTEX_ARRAY);
glEnableClientState (GL_TEXTURE_COORD_ARRAY);
with
glDisableClientState (GL_VERTEX_ARRAY);
glDisableClientState (GL_TEXTURE_COORD_ARRAY);

after the glDraw’s, then:
I can’t get a crash anymore, even with
numQuads = 8192


#2

Thanks, but to be honest, I’m unlikely to keep any of that fixed-function stuff much longer. glEnableClientState is deprecated now, and everyone uses shaders for serious work these days.

If I ever get time to update the juce GL demo to use shaders instead then I’ll probably just delete all the old code in the JUCE_USE_OPENGL_FIXED_FUNCTION sections.


#3

just curious,

in the demo a logo texture get’s created in the newOpenGLContextCreated by using regular juce code. (createLogoImage)

However, in that newOpenGLContextCreated(), shaders are not yet available, which means
OpenGLContext::copyTexture
goes through with a piece of code that still will upset shaders later on, when it creates the dynamic texture to put on the sides of the cube
(it’s not using the fixed pipeline when it does that, but since createLogoImage() already left it in a bad state, you’ll get a crash now and then)

So, to avoid random crashes, it’s not allowed to create an Image of OpenGLImageType(), and put it in a Graphics() in newOpenGLContextCreated ?

I’m looking at void OpenGLContext::copyTexture in the juce_OpenGLContext.cpp.
It seems either areShadersAvailable() is wrong, or you still need to add glDisableClientState (GL_VERTEX_ARRAY);glDisableClientState (GL_TEXTURE_COORD_ARRAY); in there. otherwise it crashes, even without the fixed-function part in the demo.

(Ps. I do love the speed with which you maintain Juce and keep up with the forum!)
Shaders are powerful, but not everything has moved on past gl2.1 unfortunately…(vmware?)


#4

Ah! Thanks very much, I hadn’t spotted that the areShadersAvailable flag wasn’t being set up early enough - it should have been done before calling the initialise method, which would avoid those old code paths. I’ve fixed that now.

Well, the thing is that without them, none of the interesting GL stuff in the library is possible, so I think the best plan for juce is to make sure it still compiles on old hardware, but not to provide anything other than a blank viewport, leaving it up to the user to write their old-fashioned GL code if that’s what they want to do.


#5

I was actually only worried that you would turn off compatibility with opengl 1/2 when the openglcontext get’s created. :slight_smile:
We still have a whole bunch of legacy opengl code that works perfectly fine at the moment, but would need a rewrite for a strict opengl 3.3 or 4.0 context.
(displaylists! ouch)

With the current context code, I get a gl3.2 context with compatibility mode on windows.
Something like Frongo’s proposal a little while back would work to have a choice between 3.2 core and compatibility mode.

thanks!


#6

[quote=“filipp”]I was actually only worried that you would turn off compatibility with opengl 1/2 when the openglcontext get’s created. :slight_smile:
We still have a whole bunch of legacy opengl code that works perfectly fine at the moment, but would need a rewrite for a strict opengl 3.3 or 4.0 context.
(displaylists! ouch)

With the current context code, I get a gl3.2 context with compatibility mode on windows.
Something like Frongo’s proposal a little while back would work to have a choice between 3.2 core and compatibility mode.

thanks![/quote]

Yeah, I certainly won’t do anything to stop you creating an openglcontext on pre-shader versions, but would eventually like to remove some of the old-fashioned helper functions from the library if possible.