[Interest] Confused about High-DPI icons...
elvstone at gmail.com
Sun Mar 17 10:46:46 CET 2019
Den fre 15 mars 2019 kl 06:07 skrev Nikos Chantziaras <realnc at 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
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."
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
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
> Interest mailing list
> Interest at qt-project.org
More information about the Interest