Important: Please read the Qt Code of Conduct -

QGraphicsView using QOpenGLWidget as viewport, bad text rendering

  • I'm subclassing a QScrollBar to provide 60fps smooth scrolling for my QGraphicsView which contains items with pixmaps and text, so I'm trying to take advantage of GPU rendering to reduce CPU usage.

    Here's the openglwidget constructor:

        explicit OpenGLViewport(QWidget *parent = nullptr) : QOpenGLWidget(parent)
            QSurfaceFormat fmt = QSurfaceFormat::defaultFormat();

    And in the graphicsview constructor:

        auto *gl = new OpenGLViewport(this);

    paint function of the graphicsitem:

    void AlbumFrame::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
        painter->setRenderHint(QPainter::Antialiasing, true);
        painter->setRenderHint(QPainter::SmoothPixmapTransform, true);
        painter->setRenderHint(QPainter::TextAntialiasing, true);
            painter->drawPixmap(coverp, albumcover);
        QFont font("Microsoft YaHei", 9);
        painter->drawText(QRectF(0, 160, 160, 25), Qt::AlignVCenter | Qt::AlignLeft, display_albumname);
        painter->drawText(QRectF(0, 185, 160, 25), Qt::AlignVCenter | Qt::AlignLeft, display_singer);

    This is painted on openGLWidget:
    And this is on the original widget viewport.

    Obviously the text is painted in weird shape. Moreover, I don't see any decrease in CPU usage when scrolling. Since I don't know much about openGL, I may have missed some basic part... Any help will be appreciated!

    Qt version is 6.0.2, compiler MSVC2019 64bit.

  • @closer_ex
    OpenGL support in GraphicsView never really got anywhere. They realized the architecture of GraphicsView isn't a good match for hardware accelerated rendering, and created SceneGraph and QML.

    In my experience, using OpenGL with GraphicsView produces inconsistent results with painting artifacts, and not that much of a performance gain. Actually, for a CPU-only engine, plain GraphicsView is pretty fast.

  • @Asperamanca Thanks for the reply! That explains why there is so little info about this combination on google.

    And yes the CPU rendering engine is fast, it was the debug build that should take responsibility for high CPU usage( and so much higher than I thought it would), the release build only consumes about 3% CPU resources while the debug one blows up a core, causing ui thread to stutter.

  • @closer_ex
    They added a lot of highly expensive Q_ASSERT-statements sometime in Qt 5. That might be the cause of high CPU usage.

    EDIT: You can verify that by defining your own Q_ASSERT and Q_ASSERT_X macros before including the first Qt header file.

Log in to reply