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