Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QGraphicsView / QGraphicsScene not updating (intermittently!)



  • I have a problem with my QGraphicsView (subclass) not fully updating sometimes. This is a desktop application (Qt5.9.2 gcc, CentOS 7) that can be thought of as a camera field-of-view moving over a surface taking pictures. The field-of-view box (blue in images below) is a QGraphicsRectItem, and the green patches are QGraphicsPixmapItems. The dotted lines are QGraphicsLineItems. QGraphicsScene inside a QGraphicsView (non-OpenGL). Pretty simple stuff.

    When I run an automated region "scan", sometimes (unpredictably) the graphics stop updating, although the graphics items have all been created and added to the scene. I can grab where the FOV box should be and it moves as it should, but you can't see it until mouseRelease. In other words, the QGraphicScene "thinks" everything is there, but the view stops updating.

    I have tried adding QGraphicsScene::update() and even invalidate() at the end the updateScene() method, and that didn't fix it. The QGraphicsView::viewportUpdateMode setting DOES change the frequency of the hang occurring (FullViewportUpdate being the worst), but does not eliminate it happening. Sometimes just clicking in the view with the mouse causes an update and the graphics appear as they're supposed to (see images below). Sometimes not...

    No, I can't make a small application to reproduce this. Sorry. It's part of a big application, and it is an intermittent problem; not readily reproducible.

    I would first and foremost like to figure out why the visuals are "hanging" in the QGraphicsView. Nothing I've tried to do to "force" an update (including executing the repaint() and update() method on the viewport widget directly) seems to make any difference.

    As a workaround, when my process of collecting an array of patches finishes, I'd like to be able to force some sort of update to be sure all of the QGraphicsItems get displayed.

    Anybody else ever run in to anything like this? Any ideas on what else I can try?

    Image 1
    (in the first image below are two completed arrays of patches, then the hang occurred after gathering the 2nd QGraphicsPixmapItem of the third array. It completes the full array of collecting patches from the camera and adds the QGraphicsPixmapItems to the scene, but the visuals don't update)
    TNailHang.png
    This is a typical failure mode, but it can happen anywhere during the collection of the array of patches, not just on #2.

    Image 2
    (in this case, when I clicked in the QGraphicsView when it was "stuck", it then properly updated to look like this)
    TNailHang1.png


  • Lifetime Qt Champion

    Hi,

    Would it be possible to test that application against a more recent version of Qt ?



  • @SGaist I do have 5.13 and I'll test against that.

    Another wildcard is that I've been developing this with an older version of "xorg" and just recently updated to the latest offered under CentOS7. I can also check if I can repeat this with an older version of xorg on a different machine. Frustrating.



  • Now I've tried it against 3 versions of X11 (xorg) and both the Qt5.9.2 and Qt5.13.0 versions and I can encounter the problem in all of the configurations.

    Since it's so inconsistent, I'm wondering if I have some threading and/or signal/slot synchronization problem. I'll start looking at that.



  • The automated "scan" process was running as its own thread and although I tried using mutexes and everything else I could, I think I was still getting enough uncertainty in the delivery of signals that the QGraphicsView was getting confused. I changed the code so that the scan does not run in a separate thread and things seem to be working now.

    I also tried using a QOpenGLWidget as the viewport of the QGraphicsView and that worked to eliminate the graphics view hangs, but I had other artifacts and would prefer not to rely on OpenGL graphics implementation if possible.


Log in to reply