[Development] Revisiting high-DPI configuration options
frank at hemer.org
Fri Jun 17 14:54:45 CEST 2016
On Friday 17 June 2016 12:06:06 Morten Sorvig wrote:
> Hi all,
> 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
> recompile Qt.
> 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
> own QT_FONT_DPI).
> 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,
> using qRound.
Can you give a hint on what causes these glitches and how to avoid them?
I'm not talking about general usage of fractional methods for painting here.
For example when drawing to a pixmap (sized for the 'real' screen resolution)
and then updating just a sub-rectangle of this pixmap, for some (and really
only some) fractional scale factor values there are glitches around that sub-
rectangle where the background color of the window shines through.
What is causing this?
> 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.
What is the reason for not aiming towards supporting fractional scale factors
on the long run? What is the real challenge here?
> 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
> - X11/Windows: Test how fractional scale factors work (if applicable)
> QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough
> - 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,
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.
I really appreciate your effort in improving this:-)
More information about the Development