First off sorry for the bad title, I couldn't think of what to call it exactly.
I've run into this problem when drawing and loading textures on separate threads using the same context. When it's loading the textures it starts drawing each of most recently loaded texture for one frame, then goes back to normal.
Now I am locking and unlocking the OpenGL code, and I debugged it just to check to see if the locks were working and they were. However what leads me to believe it has something to do with threading is because I changed my drawing to run on the same thread and this problem didn't occur. So the simple solution I thought was to just create a second context and have them sharing state, but I'm still a little worried that this problem might actually be something big and so might reappear much later and so would be trickier to fix.
The strange thing about this is it only happens if I create another GUI element (the GUI makes use of OpenGL) and use that to draw, when loading up the textures. And from debugging it's drawing code it seems that regardless the texture that's being bound at the current active texture (GL_TEXTURE0) it is getting replaced by the loaded texture somewhere. It can be avoided by changing the active texture to anything other then GL_TEXTURE0, but like I mentioned above this just seems a way of covering up the problem.
Just to explain what is happening from the application side of things. It draws a table with multiple elements, then depending on what you select it then creates a second table and starts drawing that (the second table is what I was referring to above by "create another GUI element"). Then when you select what you want it will then load up the textures but still drawing the same table. Except then for the next few frames, each frame is of one of the textures being loaded.
I've run into this problem when drawing and loading textures on separate threads using the same context. When it's loading the textures it starts drawing each of most recently loaded texture for one frame, then goes back to normal.
Now I am locking and unlocking the OpenGL code, and I debugged it just to check to see if the locks were working and they were. However what leads me to believe it has something to do with threading is because I changed my drawing to run on the same thread and this problem didn't occur. So the simple solution I thought was to just create a second context and have them sharing state, but I'm still a little worried that this problem might actually be something big and so might reappear much later and so would be trickier to fix.
The strange thing about this is it only happens if I create another GUI element (the GUI makes use of OpenGL) and use that to draw, when loading up the textures. And from debugging it's drawing code it seems that regardless the texture that's being bound at the current active texture (GL_TEXTURE0) it is getting replaced by the loaded texture somewhere. It can be avoided by changing the active texture to anything other then GL_TEXTURE0, but like I mentioned above this just seems a way of covering up the problem.
Just to explain what is happening from the application side of things. It draws a table with multiple elements, then depending on what you select it then creates a second table and starts drawing that (the second table is what I was referring to above by "create another GUI element"). Then when you select what you want it will then load up the textures but still drawing the same table. Except then for the next few frames, each frame is of one of the textures being loaded.