Jassert in bindTexture() (OpenGL)

General JUCE discussion
1

I’ve no doubt that this is likely through fault of my own somehow but I’m trying to understand why I might be hitting a jassert in bindTexture() inside juce_OpenGLGraphicsContext.cpp (see below)

void bindTexture (const GLuint textureID) noexcept
    {
        jassert (currentActiveTexture >= 0);

        if (currentTextureID [currentActiveTexture] != textureID)
        {
            currentTextureID [currentActiveTexture] = textureID;
            glBindTexture (GL_TEXTURE_2D, textureID);
            JUCE_CHECK_OPENGL_ERROR
        }
        else
        {
            #if JUCE_DEBUG
             GLint t = 0;
             glGetIntegerv (GL_TEXTURE_BINDING_2D, &t);
             jassert (t == (GLint) textureID); // <-- this is the jassert I'm hitting
            #endif
        }
    }

Unfortunately this is NOT using the latest tip of JUCE (it’s the last commit of 4.1.0 before switching to 4.2.0), but all I want to know is if there are any ideas as to what someone would have to do in order to trigger this jassert?

The assert seems to always be hit in the same place (bound to be clue here I’m sure - I just can’t see it yet). The chunk of code that causes it basically creates a hash based on the input variables to a function, if this hash is unique it generates an image and creates an object which contains the image and hash, these are then stored in an array. It goes on to draws either the newly generated image or an image it extracted from the array based on the hash.

It’s during the drawing of the image that the jassert is triggered. The images will always contain text and transparency. I’ve also added a lock for the whole duration of the function that hopefully prevents any multi-threading issues.

I find myself hitting this jassert seemingly randomly from time to time - as far as I can tell visually it has no impact, but I would still like to find the reason behind it if possible.

One possible clue is that I think this is only happening or at least much more likely to happen if two of the images have to draw on top of each other.

Update:
It doesn’t appear to have anything to do with drawing images on top of each other. I have found two specific components that this problem occurs on vs at least 8 that it doesn’t appear to occur on (not aware of any immediately obvious differences). Also it turns out there is a visual issue, the component doesn’t seem to draw anything for that one call which looks like it occasionally flashes in use.

2

Are you doing any custom OpenGL drawing yourself? It’s possible that you hit this assertion if you mess up the OpenGL state with a custom OpenGLRenderer.

3

No literally all I have is an OpenGLContext in the editor that calls attachTo (*this) in the constructor followed by detach() in the destructor.

The reasons for drawing into a image are actually diminished with the use of OpenGL now so the function that would always seem to lead to this assert has now been replaced with just drawing straight to the Graphics context rather than caching any images. Having said that I would still love to work out what I might have done wrong. If I get a chance I’ll try and make an example project that demonstrates this issue, I can then see if it is still the case on the latest tip and share it with you if it is.

4

Hello,
I still have the problem with same setup (JUCE 5.4.4), just OpenGLContext attached, no fancy custom OpenGL drawing whatsoever, and from time to time, always on the same drawing of the same image, it will hit this. When in release, the corresponding behavior is not showing the image at all. I tried deleting, modifying it in Photoshop and reimporting it in the Projucer, same problem.
This actually happens at different parts of the software, but always trying to draw the same image (it’s a checkbox image, so there are multiple ones in my software)

EDIT : digging a bit further, it seems that it has to do with drawing the image in a component that has alpha set to 0.5 . If I comment out setting alpha to 0.5 and leave it to 1, there is no bug

1 Like
5

We are hitting this too now, but it doesn’t have any side effects in a release build at all. Not even in a debug build as I just commented out the jassertfalse for now. We are also tweaking alpha values but I don’t see what’s the problem with that. Not a big deal though, just came here because I was searching for the error, maybe it helps solving this.

6

We get this assert since JUCE 8.0.8 and the latest develop branch, but not with JUCE 8.0.7

Has something changed since JUCE 8.0.8, OpenGL related?

7

These are the only commits I could see changing any code relating to OpenGL between 8.0.7 and develop

8

Thanks for the reply.

I’m not so familiar with how OpenGL works in JUCE under the hood, but this commit (00836d) has some changes related to texture binding, which is also where the assertion is being triggered. Do you have any suggestions on how I can investigate this any further?

9

I think first confirm that commit is indeed causing the issue, then maybe if you could create a simple example that triggers the assertion, and hopefully we’re then able to reproduce the issue.

10

For me, it gets triggered if I have juce::Component as a child of an OpenGL context (so I can use my own shaders) and the children use setBufferedToImage ( true );

When I switch my app to kiosk mode and back, often the children use garbage or even my textures created for my shaders.

1 Like
11

The assertion is checking that, when bindTexture() is called, the texture we last bound is still actually bound. The main thing I can think of that would break this assumption is if a different texture is being bound without being put back afterwards. You could check this by putting some breakpoints or logging on calls to glBindTexture that are made outside the context. I can only see a few such instances - there’s three calls in OpenGLFrameBuffer.cpp, and four in OpenGLTexture.cpp.

12

After some cleanup of my OpenGL code, I can no longer reproduce the aforementioned behavior. Using children within an OpenGL component and setting setBufferedToImage ( true ) on them now works as expected.

I then pulled the latest changes from JUCE develop (from a version that was maybe a week old) they also work as expected.

Sorry for the false alarm.

1 Like