[Development] Revisiting high-DPI configuration options
Morten.Sorvig at qt.io
Fri Jun 17 14:06:06 CEST 2016
After shipping the high-dpi update in 5.6 we’ve gotten several reports
that application scaling does not always come out as intended (see
QTBUG-52318, QTBUG-53416, QTBUG-53500, and QTBUG-54144). I’d like to
take a look at this again.
There are a lot of different configurations out there so I think one of
the things we need is field testing to verify that what we are implementing
works as intended. Ideally testers should be willing to apply patches and
The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
focus on two aspects:
1) Automatic scale factor configuration based on system settings.
2) Handling fractional scale factors (rounding).
1) Scale factor configuration. This is an issue on some platforms:
- (Windows has landed on using per-screen logical DPI and should be fine.)
- Android: We have some reports of Qt on some devices getting incorrect
scale factors. If you have such as device available for testing I’d like
to hear from you.
- X11: Currently uses _both_ logical and physical DPI. This means the
application comes out wrong if either are incorrectly set.
Physical DPI is great for getting an accurate per-screen scale factor
but has two flaws: We can’t always trust it (and we don’t know _when_
we can trust it), and it does not respect user settings (including our
I suggest we move x11 over to using logical DPI (similar to Windows),
perhaps having physical DPI as an option.
It is my impression that getting per-screen logical DPI values from X11
is difficult. I’d very much appreciate feed back here from users on
various desktops (KDE, GONME, other): Are there settings we can use? We
need an API or read a config file.
2) Handling fractional scale factors
This is relevant for e.g. a Windows setting of 250%, corresponding to
a scale factor of 2.5. Presenting a fractional scale factor to the app
may cause graphics glitches, so we round it to the nearest integer,
However, mathematically correct rounding may not be the best kind of
correct in this case. In particular we should consider rounding factors
of .5 down instead of up. The effect would be presenting an UI that
is visually slightly smaller than it should be, over the current
behavior of presenting an UI that is slightly larger.
In addition we have the option of tweaking the DPI reported to the
application to account for the remainder from the rounding.
So for the 250% case we can report a devicePixelRatio of 2 and a
DPI of 144. This relies on the existing DPI handling support (fonts
scale automatically, rest of UI may not), but since the offset from
the base DPI is small it might be OK.
Finally, we should consider adding an option to simply let the fractional
scale factor through. We have user reports of applications that work
fine with such factors, save for one or two bugs in Qt. These are typically
custom-styled applications that do not rely on the Qt platform styles.
Allowing this as an option would not mean that fractional factors are
supported in Qt (for the formal meaning of “supported"), nor that we
necessarily spend time on fixing related issues.
How do I test the new implementation?
- Check out the patches for 5.6: (this is the last change in the series)
- Compile qtbase and tests/manual/highdpi
- Run "./highdpi --metrics", or test with an application.
- X11: Check if using the logical or physical DPI works for your displays
QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_USE_PHYSICAL_DPI=0|1 ./highdpi --metrics
- X11/Windows: Test how fractional scale factors work (if applicable)
QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough ./applicaiton
- X11 (mostly): Are you using non-Qt applications on the high-DPI displays?
How do you configure them?
As before, QT_SCALE_FACTOR can be used to set any scale factor for testing, and
QT_FONT_DPI can be use the set the logical DPI (now expanded to work on Windows
and macOS in addition to X11).
Please report back here, or directly to me, or on tracking bug QTBUG-53022.
Both reports of success or brokenness are interesting. Include the output from
"./highdpi —metrics” with the report.
Also feel free to ask questions if anything is unclear.
More information about the Development