[Development] Revisiting high-DPI configuration options

Morten Sorvig Morten.Sorvig at qt.io
Tue Jun 21 20:02:05 CEST 2016

> On 17 Jun 2016, at 22:49, Thiago Macieira <thiago.macieira at intel.com> wrote:
> Creator is also a bad citizen (worst of all Qt 5 applications I've tested), 
> but I did not test it again in the scenarios above. When I tested before, I 
> had to find the right combination that would make both the QML and non-QML 
> parts of the UI look reasonable. Under some configurations, the text editor was 
> the right size but the Welcome screen, the left and bottom panels would look 
> too big, etc.

Creator’s lot in life - taking the fall for bugs in Qt :)

Anyway, inconsistencies like these is something I’m seeking to avoid with the
new patches: we want to have uniform scaling for all app content where everything
comes out either correct or not. This should make it easier to judge what effects
setting options has.

If you’re still seeing things like this even with the most recent patches
(see update below) that’s something I think we should take a closer look at.

> But you apparently removed the ability to set the scaling per-monitor. So this 
> brings Qt back on par with other X11 HiDPI-aware applications. Hence the reply 
> I get from everyone: use Wayland.

Yes. I left that one out in my description, the code was still there.
I made a couple of the changes to the implementaton (see commit de827565)
and included it in the --metrics output.

The configuration workflow is now:

1) Set Qt::AA_EnableHighDpiScaling or QT_AUTO_SCREEN_SCALE_FACTOR=1

   This will use the per-screen logical DPI as reported by the
   platform plugin.

2) If not happy then

2a) Override the global logical DPI: QT_FONT_DPI=N

2b) Use physical DPI: QT_USE_PHYSICAL_DPI=1

2c) Set scale factors manually: 

    This will disregard the DPI values the platform plugin reports for
    the screens in question. The screen name in the second form is
    QScreen::name(). (Using the screen name is possible already in 5.6).

2d) Perhaps tweak the rounding policy. (factors directly specified in env.
    variables are not rounded).

I think using screen names can be a good match for cases where you are
sometimes connecting to external screens, provided that the string returned
by name() is unique for each screen.


More information about the Development mailing list