-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.8.4
When a QOpenGLWidget is updated together with its siblings, the widget can be seen updating unnecessarily large area of the backing store which results in a large texture upload.
In a simple application with the following setup:
QMainWindow
--QFrame
--QOpenGLWidget
Calling update for the QFrame only will trigger a change that is limited to the boundaries of QFrame.
qt.qpa.backingstore: Composing and flushing QRegion(9,9 1902x593) of QWidgetWindow(0x1dadacde520, name="QMainWindowClassWindow") at offset QPoint(0,0) with 1 texture(s) in QPlatformTextureList(0x1dadad07cf0) via swapchain 0x1dadad1bcc0
Calling update for the QOpenGLWidget only seems to only update the FBO.
qt.qpa.backingstore: Composing and flushing QRegion(null) of QWidgetWindow(0x1ffa014e9a0, name="QMainWindowClassWindow") at offset QPoint(0,0) with 1 texture(s) in QPlatformTextureList(0x1ffa01778b0) via swapchain 0x1ffa018bdf0
However, calling update for both QFrame and QOpenGLWidget at the same time will trigger an update in an area that encloses both the QFrame and the QOpenGLWidget which forces the "hole" for the QOpenGLWidget to be repainted although the geometry has not changed. Due to a large area of update, a texture of corresponding size is uploaded as well. This seems unnecessary as in reality the only relevant area of the backing store that would've been changed is the area occupied by the QFrame.
qt.qpa.backingstore: Composing and flushing QRegion(size=2, bounds=(9,9 1902x1192) - [(9,9 1902x593), (9,608 1902x593)]) of QWidgetWindow(0x1a52ef1eb80, name="QMainWindowClassWindow") at offset QPoint(0,0) with 1 texture(s) in QPlatformTextureList(0x1a52efde340) via swapchain 0x1a52ef5bdf0
Steps to reproduce the issue:
- Run the attached project
- Observe logging