Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Image updates not painting
jmcintyre last edited by
We've recently migrated from Qt 5.1 to 5.3.1 and have run into a problem where none of the 2D imaging updates on change. For example, when a QGraphicsPixmapItem is updated with a new image, it continues to display the old image until another QWidget is overlaid on top of that item and then removed (note that merely dragging another window over this window does not cause the image to refresh). This issue effects all images including those loaded inside of a webkit control.
I have attempted to force paint calls on several widgets in different ways and to the root window itself, but the only ways I've found to refresh is to add a widget on top and then to remove that widget or to hide and then show the widget again.
Here is some special case data about our application that may add to the complications:
We are rendering OpenGL onto a QGLWidget and these images that aren't updating appear in the same window, but do not overlap the QGLWidget. We also have our own run loop that calls the following to run our Qt events:
Application was originally written against Qt 4, but has been running in Qt 5 since 5 was released.
OpenGL build of Qt 5.3.1 (OpenGL 3.2 configed for use by our contexts)
Visual Studio 2013
Any ideas would be appreciated. Thanks.
jmcintyre last edited by
I've learned a bit more about the issue. If I do not create the threaded QGLWidgets, the 2D elements work correctly. We're doing some complicated things with OpenGL that might be gumming up the works on this new vesions of Qt.
- We have multiple QGLWidgets and threads.
- The context for each rendered QGLWidget is created on the main thread, but the ownership of the context is shifted out to a render thread using the code:
m_pGLWidget->context()->moveToThread( m_pThreadData->m_newThread );@
swapBuffer is then called on the render thread instead of the main thread.
- Auto buffer swap is disabled.
- There is an additional parentless QGLWidget that is hidden from view and never drawn to. Instead, the context of that widget is used by the main thread to perform certain opengl management functions that better run in preparation before the render thread takes over. swapBuffer is never called on this context, but it is regularly flushed. This widget is still created even in the scenario that I described earlier that works and 2D images update (only the widgets with contexts on separate threads were removed).
It is an odd setup, but it has worked since Qt 4.7 and only had to make adjustments in 5 to deal with the thread moving restrictions for qt managed ql contexts. Does anyone have ideas of areas I can look into? Also, if there are any sections of code that would be helpful for me to post, please let me know.
Hi and welcome to devnet,
You should rather ask this on the interest mailing list. You'll find there Qt's developers/maintainers (this forum is more user oriented) Don't forget to subscribe first