Nominate our 2022 Qt Champions!

High DPI Screenshot of QtWidget Application

  • Hello,

    I want to make a high DPI screenshot of an Qt widgets application, while the app is running on a normal monitor without any DPI scaling. Therefore I'm currently using a QPixmap as rendertarget for the widget. I have made a minimal reproduction example:


    #include <QApplication>
    #include <QPushButton>
    #include <QVBoxLayout>
    int main(int argc, char *argv[])
        QApplication a(argc, argv);
        QVBoxLayout layout;
        QPushButton btn("Hello");
        QWidget w;
        w.resize(200, 150);;
        QPixmap pixmap(800, 600);
        return a.exec();


    QT += core gui widgets
    CONFIG += c++11
    SOURCES += main.cpp

    When I run this code, this is the result:
    The text is rendered fine with high resolution, but the border of the button is still rendered in low resolution.

    When I run this code with QT_SCALE_FACTOR=4 ./test the result looks like what i want:
    But the sideeffect is that the whole application is scaled by factor 4.

    Does anybody have an idea how to make a high resolution "screenshot", while the app is running in normal resolution?

    I use Qt 5.14.0 on Ubuntu 18.04.


  • Lifetime Qt Champion

    It's really not the same with high resolution as high DPI.
    You can pretend your normal monitor has many pixels but the actual Qt scaling
    is not in effect since the DPI is at a normal level.
    However, using QT_SCALE_FACTOR you enable that scaling so
    for a true High DPI shot, you need that and yes its only for whole app.

  • I thought that pixmap.setDevicePixelRatio(); is for setting the DPI of the Pixmap. And as you see on the screenshot this works correctly for text and the general layout calculation is correct. Only the rendering of the border of the button is rendered with low DPI.
    When the resolution of the Pixmap is generally not meant to be used as High DPI, then I don't understand why it works for the text. So is this a bug in Qt that there is an inconsistency between rendering of text and button border, or this defined behaviour?

Log in to reply