Den fre 15 mars 2019 kl 06:07 skrev Nikos Chantziaras <rea...@gmail.com>: > > On 14/03/2019 16:41, Matthew Woehlke wrote: > > On 13/03/2019 18.41, Sérgio Martins via Interest wrote: > >> Do you have: > >> > >> QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); > > > > Uh... *why* is that not the default? Without that, I still get a scaled > > UI, but it is an ugly mix of stuff that's *properly* scaled (and making > > use of the higher resolution) and stuff that isn't. > > > > AFAIK, applications that don't turn that on are still susceptible to > > scaling problems... > > I still don't understand what the proper way to support high DPI > displays is... In some places I see that using > QApplication::setAttribute(Qt::AA_EnableHighDpiScaling) is for legacy > applications that don't natively support it. Yet, if I don't use that, > my applications are blurry. > > The documentation is silent about this.
I've also always been a bit confused about this. The docs describe the Qt built-in scaling as: "Qt 5.6 supports cross-platform high-DPI scaling for legacy applications, similar to the scaling done natively by macOS. This allows applications written for low-DPI screens to run unchanged on high-DPI devices." and then also: "Migration of Existing Applications In order to get an application designed for low DPI values running on a high resolution monitors quickly, consider one of the scaling options (let the application run as DPI Unaware on Windows or set the environment variable QT_AUTO_SCREEN_SCALE_FACTOR to "1". These options may incur some scaling or painting artifacts, though. In the longer term, the application should be adapted to run unmodified: Always use the qreal versions of the QPainter drawing API. Size windows and dialogs in relation to the screen size. Replace hard-coded sizes in layouts and drawing code by values calculated from font metrics or screen size." (From https://doc.qt.io/qt-5/highdpi.html) I've always interpreted these pieces of docs as saying the Qt built-in scaling is meant as an easy way to get something acceptable, or for legacy applications that want something acceptable, but that the "proper" solution is to not enable it and instead make sure the application itself is DPI aware. We're trying to follow this advice, and not using the Qt scaling in our desktop app, but it is a bit of a struggle since Qt has had problems following this advice themselves in places, and especially reacting on its own to DPI changes (whether they occur through moving the app to a new screen, the screen setup changing, the resolution changing, et.c.) and to Windows screen scaling option changes (which is not really a true scaling, but anyway). It has also been a struggle sometimes because there has been issues with some icon engines (the one on Mac in particular) not reacting to DPI changes properly. I'm unsure what the status is nowadays, but I know we have it on our TODO to make sure the app works well in hidpi/mixed dpi setups. We do enable hidpi pixmaps support though, though we use SVGs as icons, not 2x versions (not sure if that is officially supported/recommended). Sorry for not giving much advice here, just a fellow developer lamenting that hidpi is quite hard to get right still, if following the official recommendation of not using Qt built-in scaling for new applications. Elvis > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
