OpenGL 2D rendering RED on resize

General JUCE discussion
1

I have been using openGL for component 2D rendering since it showed up in Juce, and it’s always been amazing of course.

Recently, I notice that if I resize my top level component, I get flickers of red as the openGL canvas (presumably) resizes / swaps / clears / redraws. This shows up as bars on the right and lower sides of the component of course.

I suspect this may have always been happening but previously it wasn’t bright RED.

Is it possible that either the openGL clear color, or some other color, has recently changed?

Is there a way I can set it manually? I don’t see that anywhere at a quick glance.

The “stuttering” can be seen in this topic, when you resize the component:

I assume that is somewhat inevitable, since openGL is on a different thread, but it’s not really a problem as long as the extra area is white.

This is on mac OS11 by the way.

Red background on openGL component
2

Aha! Looks like I can clear manually in resize() using a helper.

Still seems like it might be better to default clear GLContexts to white, but for anyone else getting this issue, adding this sort of thing to the resize seems to do the trick.

if (OpenGLHelpers::isContextActive())
{
     OpenGLHelpers::clear(Colours::blue);
}
1 Like
3

This has always driven me crazy as well. It’s confusing how the frame can change sizes faster / slower than the internal window it contains, but the red background it displays is the worst of it. Thanks for the tip! Gonna give it a shot as well

4

This just confused me… I get false back for isContextActive() when I initialize the render on the top level component like:

mGLContext.attachTo(*this);

Is this different than how you’re rendering via OpenGL?

5

Well, it doesn’t attach immediately.

I use that clear call in the resized() method.

6

hmm yeah in my resize it was false on return

7

I’m seeing the same issue as well.
The correct clear should probably done in Juce itself rather than in user code no ?

1 Like
8

I got the same problem as jakemumu.
Even though I attached my GL context using mGLContext.attachTo(*this) I get false for isContextActive in the resized function.

Here is how I could solve it instead:
I subclass juce::OpenGlRenderer. And in its renderOpenGl() function I put this:

void MyOpenGlRenderer::renderOpenGL()
{
    if (OpenGLHelpers::isContextActive())
    {
         OpenGLHelpers::clear(Colours::blue);
    }
}

Now I only have to tell my GL context, that I am using a custom renderer, by calling:

mGLContext.setRenderer(&mMyOpenGlRenderer);

Seems to work fine so far (fingers crossed)!

1 Like
OpenGLHelpers::isContextActive() crashes in ProTools
9

Hey – just wanna follow up on this, did this prove to be a stable method for getting rid of that red flashing?

10

NO!

This should be avoided in fact.

I was unaware, but openGL calls (like OpenGLHelpers::isContextActive()) are not guaranteed to be thread safe (so should only be called from paint and renderOpenGL).

So far I have no solution for this, I’m just dealing with the red.

Apparently, it only happens on mac though, FWIW.

11

Are you referring to Aarons solution or to my solution?

I am still using my solution (which is different from Aarons solution). And it has been fine so far. No more red flashing. And no crashes or asserts with it so far (don’t have Pro-Tools though, so cannot test there). As mentioned above, in my solution I subclass the juce::OpenGlRenderer.

That way I am only calling OpenGLHelpers::isContextActive() from within OpenGlRenderer::renderOpenGL(). Which should be OK, if I understand Aaaron and Reuk
correctly.

12

Oh, nice, I hadn’t seen this.

Your solution does seem to work. Previously AAX was crashing here, this seems to straighten it out, and no more red.

Nice work!