composing a very small QWidget and a QOpenGLWidget in the same large top level widget is extremely slow

Build and execute the attached test case. After starting it, resize the left dock widget by any amount - it is important that its size does not fluctuate with the length of the text it contains, and a manual resize causes it to remain fixed.

The default state of the test application's main window is docked QWidget + QOpenGLWidget central widget. Note that, from this state, FPS are increased dramatically by doing any of the following:

• hiding the docked widget
• undocking (floating) the docked widget
• switching from using a QOpenGLWidget as the central widget's viewport to using a QGLWidget

Note that, in the slow state, the size of the docked widget has little impact on FPS. This surprised me, and may represent a bug: when forced to resort to texture composition for a raster widget, a texture the size of the top level widget being composed is uploaded, regardless of the size of the raster widget. If the top level widget is large, zeroing the mostly-unused texture and uploading it both take many milliseconds. As a result, I must use QGLWidget in place of QOpenGLWidget to avoid prompting composition.

It is actually far faster to compose a small raster widget and a single, large QOpenGLWidget-viewport QGraphicsView by placing the raster widget in the associated graphics scene than it is to have the raster widget and graphics view as siblings composited by the top level widget!

Additional information: http://esoerik.blogspot.com/2016/06/blittextureforwidget-yeah-why-dont-you.html

The attached test case code is also available on github: https://github.com/erikhvatum/qopengl_vs_qgl_fps