Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Using `QOpenGLFramebufferObject` with `QGraphicsView`
tfm123 last edited by tfm123
QOpenGLWidgethas a GL framebuffer in which it expects everything to be rendered. This framebuffer is not the system's default framebuffer.
QOpenGLContext::defaultFramebufferObject()returns the default framebuffer. This function is used in
QOpenGLFramebufferObject::release()to rebind the default framebuffer after one is done with using one's own.
Now, for this to work with
QOpenGLWidgetit is necessary for
defaultFramebufferObject()to return not the system's default, but the framebuffer used by the widget.
release()will leave you rendering into the system's default framebuffer
0while the widget expects you to render to, say, framebuffer
Looking at the sources shows that
QOpenGLWidget, before calling a virtual
paintGL()method, sets a flag on
QOpenGLContextto make its
defaultFramebufferObject()method return the correct framebuffer.
paintGL()method do therefore work as expected.
So far so good. This is also all documented like this.
We are, however, using
QOpenGLWidgetas viewport for
QGraphicsView. When using
QGraphicsEffect::draw()the aformentioned intialization step that modifies
QOpenGLContext::defaultFramebufferObject()'s behaviour seems to be missing. A call to
QOpenGLFramebufferObject::release()leaves you with the wrong framebuffer bound. We have to manually save the framebuffer id before
QOpenGLFramebufferObject::bind()and restore it later.
Now my question is: Are we misusing
QOpenGLFramebufferObjector is there an oversight in
QGraphicsView, failing to set the correct default framebuffer before calling any user-overriden
I wouldn't say an oversight but likely you have a use case that has not happened before. Also QOpenGLFramebufferObject is a pretty new class compared to QGraphicsView.
I'd recommend brining this to the interest mailing list. You'll find there Qt's developers/maintainers.