glBindFramebuffer does NOT produce error on different context

Hello!

Well, there's a very strange issue that I've come across recently. I'd better start directly with an example:

I've created a class myGLWidget : public QGLWidget (ok, I know it's an obsolete class. I'm using qt v5.15.2 and let's say it's not possible to change to QOpenGLWidget). I've re-implementd initializeGL, resizeGL and paintGL. They actually do nothing. Just a clear color and a glViewport in resizeGL.

Now, I've created a simple application where the main window consists of the following:

1) Two myGLWidget objects where the second GLWidget shares the context with the first one (passed as argument to the constructor)

2) Two QPushButtons. The first starts a painter on the first glwidget and calls painter.drawText(0, 0, "qwe"). The second button starts another QPainter on the second glwidget and calls: painter.drawText(0, 0, <a_long_string_with_various_special_characters>)

The process:
1) Push the button1: Since it's the first draw of text, Qt needs to create a textureGlyphCache. So, creates an fbo (say fbo1), binds it and draw the glyphs to cache.

2) Push the button2: Again, since it's the first time for this glwidget (say glwidget2) to draw text, Qt search first if any textureGlyphCache exists and if not, it creates it. At this point, the contexts are sharing resources, so, Qt finds the previously created textureGlyphCache. When trying to use it checks its size for the new text (<a_long_string_with_various_special_characters>) . It does not fit (or contains new characters) so it tries to call resizeTextureData. And now the problem arises: The current context was set to the second one and at this point Qt calls glBindFramebuffer(fbo1) which does NOT produce any gl error! This normally should produce GL_INVALID_OPERATION except if the very first bind was realized with glBindFramebufferEXT.

The checks I've done:
1) I override the function pointers of glBindFramebuffer, glBindFramebufferEXT, glGenFramebuffer, glGenFramebufferEXT in order to be sure that the calls from Qt end up to call what they intend to. This is, glBindFramebuffer actually calls glBindFramebuffer and not glBindFramebufferEXT etc. Core function pointers differ from the EXT one.

2) If I try to do something similar in the above example, this is, to create an fbo by call glGenFramebuffer while the current context is the first one and then try to bind that fbo while the current context is the second one gives GL_INVALID_OPERATION (as expected)

Now, you'll ask me where's the problem! The problem is that in my actual program I get an invalid operation when Qt tries to do the same exact process. Of course in my program the things are far more complex, so, I try to understand what's happening here. Is it possible that Qt in some way, during initialization of opengl function pointers do any kind of function override in order to always call the EXT functions instead of the core ones?

ps: The QPainter is created and destroyed after drawText. The context of the target glwidget becomes current before QPainter begins.

Oh well, after a week of searching I've come to conclusion that it's actually a Qt bug. The whole trick in the above simple example was that initially, when Qt first creates the textureGlyphCache, it does NOT bind the newly created fbo! Later, when resizeTextureData is called, glFramebuffer is called for first time for that fbo. That's why I wasn't get any opengl error. So, in the above example, if you just create another glwidget and try to drawText with QPainter and the textureGlyphCache needs to be resized again you'll end up with opengl error since the current context is the 3rd one but the fbo to bind was firstly bound when current context was the 2nd one.

I don't know if this is fixed in later versions of Qt, but it's surely a bug. The same goes also if you are drawing gradient colors. If I'm not wrong, Qt also caches gradients. Most probably the issue appears for that.

If anyone knows if this is fixed in a newer version of Qt, please, reply to this thread. I'll close it in few days. Thanks for your time.

Quote:

---

Oh well, after a week of searching I've come to conclusion that it's actually a Qt bug.

---

You're using QGLWidget, which you acknowledge is deprecated. If you make a toy project using QOpenGLWidget, do you have the same issue? If not, then maybe you need to bite the bullet (or convince your overlords to bite it) and revise your app to use the new API.

I've checked the code from qt4.x to qt6.5. The code is the same with the difference that instead of having QGLTextureGlyphCache, Qt uses QOpenGLTextureGlyphCache which is used with the same way. I'm almost sure that the bug still exists, but ok, I must create a simple example with Qt6.