Details
-
Suggestion
-
Resolution: Done
-
P2: Important
-
5.6.2, 5.9.2
-
CentOS Linux release 7.3.1611, x86_64,
nVidia Quadro M4000 (nVidia driver 375.39),
3D vision 2 wireless glasses kit
stereo monitor Benq XL2720
(same configuration than in
QTBUG-59636)
-
ee2dbcada8 (qt/qtbase/dev) ee2dbcada8 (qt/tqtc-qtbase/dev), c450f6d21 (dev)
Description
This is a follow-up of the webinar Qt graphics AMA from November 16 2017 where it has been recommended to open this case.
It is not currently possible (tested in 5.6.2 and 5.9.2) to deal with hardware stereo with a QOpenGLWidget, the replacement class for QGLWidget, marked as deprecated. In this regard, QOpenGLWidget is not a full replacement of QGLWidget.
With QGLWidget, once the execution reaches paintGL(), the bound framebuffer for drawing and reading is the default framebuffer. Therefore, if you requested a stereo context with QGLFormat, you have access to the back left and back right buffers.
With QOpenGLWidget, once the execution reaches paintGL(), the bound framebuffer for drawing and reading is a FBO prepared by Qt with a single colorbuffer attachment, even if you requested a stereo context with QSurfaceFormat.
During the webinar, the proposed alternate solution was to use QOpenGLWindow instead. Unfortunately, this is not an option if you use QOpenGLWidget as the viewport set on a QGraphicsView and you try to render a 3D scene in QGraphicsScene::drawBackground() in order to have QWidgets rendered as an overlay on top of the 3D scene.
I don't know the details of the implementation of QOpenGLwidget but I imagine that it would be possible to have a FBO set with two colorbuffer attachments instead of one. The custom code in paintGL() would be able to draw in the desired attachment by using glDrawBuffer*() and after the execution of paintGL(), Qt would blit one of the them to the actual back left color buffer of the default framebuffer and the other to the back right color buffer.