Jassert in bindTexture() (OpenGL)


#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.