New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable HiDPI scaling #1428

Merged
merged 1 commit into from Oct 30, 2017

Conversation

Projects
None yet
3 participants
@Oblomov
Contributor

Oblomov commented Oct 7, 2017

Since Qt 5.6, DPI-aware applications can enable HiDPI scaling by
setting the appropriate Application attribute. This allows the windows
to adapt their rendering to the DPI of the screen holding the window,
thus automatically up/downscaling when moving between high and standard
DPI monitors.

The attribute must be set before the application is actually set up, so
use the static setAttribute() before creation. For consistency, use the
same static method for the pixmap attribute.

Enable HiDPI scaling
Since Qt 5.6, DPI-aware applications can enable HiDPI scaling by
setting the appropriate Application attribute. This allows the windows
to adapt their rendering to the DPI of the screen holding the window,
thus automatically up/downscaling when moving between high and standard
DPI monitors.

The attribute must be set before the application is actually set up, so
use the static setAttribute() before creation. For consistency, use the
same static method for the pixmap attribute.

We restrict this feature to 5.9 and higher only, since in earlier
Qt versions it had some potentially unfortunate bugs.
@Emdek

This comment has been minimized.

Show comment
Hide comment
@Emdek

Emdek Oct 30, 2017

Member

I guess that we can merge it now and gather some feedback from users.

Member

Emdek commented Oct 30, 2017

I guess that we can merge it now and gather some feedback from users.

@Emdek Emdek merged commit 3f16c7c into OtterBrowser:master Oct 30, 2017

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

My feedback.

Good (old)
screenshot_2017-10-30_14-15-37

Meh (weekly199)
screenshot_2017-10-30_14-16-04

Get it away from me no no no no no :( :( :( :( (this)
screenshot_2017-10-30_14-16-35

Member

Frenzie commented Oct 30, 2017

My feedback.

Good (old)
screenshot_2017-10-30_14-15-37

Meh (weekly199)
screenshot_2017-10-30_14-16-04

Get it away from me no no no no no :( :( :( :( (this)
screenshot_2017-10-30_14-16-35

@Emdek

This comment has been minimized.

Show comment
Hide comment
@Emdek

Emdek Oct 30, 2017

Member

@Frenzie, extra zoom for web page?
Which Qt and QtWebKit versions are you using?

Member

Emdek commented Oct 30, 2017

@Frenzie, extra zoom for web page?
Which Qt and QtWebKit versions are you using?

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

Webpage zoom is fine(ish), although it should be at the same level as this mystery browser. But anyway, webpage zoom is pretty much a total non-issue, except for first impressions. (You could argue that everything's a total non-issue because you can use your own custom GUI CSS, but that's taking it a bit far.)

screenshot_2017-10-30_14-30-17-fs8

No, setting aside the fact that it's at 2x instead of something halfway, look at all of the terribly mismatched UI elements. I suppose that could be indicative of some bug in Otter in some places, although I am severely displeased by the 2x nonsense.

Which Qt and QtWebKit versions are you using?

5.6, 5.7, 5.9 and 5.10. It's always better without this. And when I compile it myself, unlike the AppImage everything's good. (Not talking about theme integration. Talking about the right amount of so-called "scaling".)

Member

Frenzie commented Oct 30, 2017

Webpage zoom is fine(ish), although it should be at the same level as this mystery browser. But anyway, webpage zoom is pretty much a total non-issue, except for first impressions. (You could argue that everything's a total non-issue because you can use your own custom GUI CSS, but that's taking it a bit far.)

screenshot_2017-10-30_14-30-17-fs8

No, setting aside the fact that it's at 2x instead of something halfway, look at all of the terribly mismatched UI elements. I suppose that could be indicative of some bug in Otter in some places, although I am severely displeased by the 2x nonsense.

Which Qt and QtWebKit versions are you using?

5.6, 5.7, 5.9 and 5.10. It's always better without this. And when I compile it myself, unlike the AppImage everything's good. (Not talking about theme integration. Talking about the right amount of so-called "scaling".)

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

Everything screams to me that this property should not be used. This probably explains why it messes things up.

http://doc.qt.io/qt-5/highdpi.html

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.
Member

Frenzie commented Oct 30, 2017

Everything screams to me that this property should not be used. This probably explains why it messes things up.

http://doc.qt.io/qt-5/highdpi.html

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.
@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Oct 30, 2017

Contributor

For comparison, this is how Otter looks like with this patch (aka with auto scale factor 1) on my mixed-DPI setup: https://imgur.com/a/g215q

(Note that the much larger subwindow in the bottom right is the one on my HiDPI display).

Contributor

Oblomov commented Oct 30, 2017

For comparison, this is how Otter looks like with this patch (aka with auto scale factor 1) on my mixed-DPI setup: https://imgur.com/a/g215q

(Note that the much larger subwindow in the bottom right is the one on my HiDPI display).

@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Oct 30, 2017

Contributor

It's possible that this is a style issue, in the sense that the style used by @Frenzie might not have proper support for high DPI. Can we have more info about your setup?

Contributor

Oblomov commented Oct 30, 2017

It's possible that this is a style issue, in the sense that the style used by @Frenzie might not have proper support for high DPI. Can we have more info about your setup?

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

@Oblomov There are two separate issues.

  1. The extremely undesirable forceful override effect caused by this patch, which is "to get an application designed for low DPI values running on a high resolution monitors quickly." Otter is not an ancient app designed for low DPI values, ergo this is bad as I've been saying for a month.
  2. The AppImage's recent overall bad styling issues. These are exacerbated by 1 but basically separate.
Member

Frenzie commented Oct 30, 2017

@Oblomov There are two separate issues.

  1. The extremely undesirable forceful override effect caused by this patch, which is "to get an application designed for low DPI values running on a high resolution monitors quickly." Otter is not an ancient app designed for low DPI values, ergo this is bad as I've been saying for a month.
  2. The AppImage's recent overall bad styling issues. These are exacerbated by 1 but basically separate.
@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

My regular setup is bog-standard Xfce. These settings are no different on any other DE.

screenshot_2017-10-30_16-25-18

Member

Frenzie commented Oct 30, 2017

My regular setup is bog-standard Xfce. These settings are no different on any other DE.

screenshot_2017-10-30_16-25-18

@Emdek

This comment has been minimized.

Show comment
Hide comment
@Emdek

Emdek Oct 30, 2017

Member

@Frenzie, forcing scaling using QT_SCALE_FACTOR=n seems to work fine for me even with this patch, and I don't see any rendering issues with Fusion style (using 1.25, 1.5 and 2), perhaps it's some bug in Qt style for GTK themes then.
Could you check if there are any issues after switching to Fusion?

Member

Emdek commented Oct 30, 2017

@Frenzie, forcing scaling using QT_SCALE_FACTOR=n seems to work fine for me even with this patch, and I don't see any rendering issues with Fusion style (using 1.25, 1.5 and 2), perhaps it's some bug in Qt style for GTK themes then.
Could you check if there are any issues after switching to Fusion?

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

@Emdek Fusion has all the same issues. Anyway, that's besides the point, which is that this change needs to be reverted. Screens incoming.

Member

Frenzie commented Oct 30, 2017

@Emdek Fusion has all the same issues. Anyway, that's besides the point, which is that this change needs to be reverted. Screens incoming.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

This is at "100%". Note how top-right Otter without this is good. Firefox is good. Bottom-right Otter with this is horrifically broken.
screenshot from 2017-10-30 15-59-10

PS All screenshots in Ubuntu 17.10 LiveUSB so we can ignore supposed issues with my bog-standard setup.

Member

Frenzie commented Oct 30, 2017

This is at "100%". Note how top-right Otter without this is good. Firefox is good. Bottom-right Otter with this is horrifically broken.
screenshot from 2017-10-30 15-59-10

PS All screenshots in Ubuntu 17.10 LiveUSB so we can ignore supposed issues with my bog-standard setup.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

Next we switch to 200%. Here you can clearly see which parts of Otter are currently broken and therefore seemingly better with this patch. (This includes QtWebKit.) With the possible exception of some workaround for QtWebKit they should be fixed the normal way.

screenshot from 2017-10-30 16-02-41

Member

Frenzie commented Oct 30, 2017

Next we switch to 200%. Here you can clearly see which parts of Otter are currently broken and therefore seemingly better with this patch. (This includes QtWebKit.) With the possible exception of some workaround for QtWebKit they should be fixed the normal way.

screenshot from 2017-10-30 16-02-41

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

Our final stop is 300%. You can clearly see how QT_AUTO_SCREEN_SCALE_FACTOR does not in fact scale properly at all but merely makes a half-assed attempt at it.

screenshot from 2017-10-30 16-08-21
screenshot from 2017-10-30 16-08-40

For me it doesn't really matter too much what you do one way or the other. I'll use environment variables, compile my own build, etc. But for people not me this is without a doubt horrible and must be reverted.

Member

Frenzie commented Oct 30, 2017

Our final stop is 300%. You can clearly see how QT_AUTO_SCREEN_SCALE_FACTOR does not in fact scale properly at all but merely makes a half-assed attempt at it.

screenshot from 2017-10-30 16-08-21
screenshot from 2017-10-30 16-08-40

For me it doesn't really matter too much what you do one way or the other. I'll use environment variables, compile my own build, etc. But for people not me this is without a doubt horrible and must be reverted.

@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Oct 30, 2017

Contributor

@Frenzie:

The extremely undesirable forceful override effect caused by this patch, which is "to get an application designed for low DPI values running on a high resolution monitors quickly." Otter is not an ancient app designed for low DPI values, ergo this is bad as I've been saying for a month.

This feature is not designed to get an application designed for low DPI values to run on a high resolution monitor seamlessly. The whole point of this setting is to declare that the application supports high DPI. Without this setting, for example, Qt will not update the devicePixelRatio information of widgets and windows, so the application cannot know how to do the scaling.

You may also notice that in my screenshot the UI elements are not messed up, and consistently scale across monitors with different DPIs. This is why I'm led to believe that the issue you're seeing is due to the Qt style being used on your system. Can you try to force Qt to use a different style to see if the issue is still present regardless of style?

Also, can you please provide the output from this program for the three configurations you screenshotted above?

Contributor

Oblomov commented Oct 30, 2017

@Frenzie:

The extremely undesirable forceful override effect caused by this patch, which is "to get an application designed for low DPI values running on a high resolution monitors quickly." Otter is not an ancient app designed for low DPI values, ergo this is bad as I've been saying for a month.

This feature is not designed to get an application designed for low DPI values to run on a high resolution monitor seamlessly. The whole point of this setting is to declare that the application supports high DPI. Without this setting, for example, Qt will not update the devicePixelRatio information of widgets and windows, so the application cannot know how to do the scaling.

You may also notice that in my screenshot the UI elements are not messed up, and consistently scale across monitors with different DPIs. This is why I'm led to believe that the issue you're seeing is due to the Qt style being used on your system. Can you try to force Qt to use a different style to see if the issue is still present regardless of style?

Also, can you please provide the output from this program for the three configurations you screenshotted above?

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

@Oblomov

This feature is not designed to get an application designed for low DPI values to run on a high resolution monitor seamlessly.

So why do the Qt blogs and docs say that's exactly what it's for?

The whole point of this setting is to declare that the application supports high DPI. Without this setting, for example, Qt will not update the devicePixelRatio information of widgets and windows, so the application cannot know how to do the scaling.

With this setting it's failing spectacularly at doing anything remotely like that, ftr.

Also, can you please provide the output from this program for the three configurations you screenshotted above?

Page doesn't load.

Member

Frenzie commented Oct 30, 2017

@Oblomov

This feature is not designed to get an application designed for low DPI values to run on a high resolution monitor seamlessly.

So why do the Qt blogs and docs say that's exactly what it's for?

The whole point of this setting is to declare that the application supports high DPI. Without this setting, for example, Qt will not update the devicePixelRatio information of widgets and windows, so the application cannot know how to do the scaling.

With this setting it's failing spectacularly at doing anything remotely like that, ftr.

Also, can you please provide the output from this program for the three configurations you screenshotted above?

Page doesn't load.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

You may also notice that in my screenshot the UI elements are not messed up, and consistently scale across monitors with different DPIs. This is why I'm led to believe that the issue you're seeing is due to the Qt style being used on your system. Can you try to force Qt to use a different style to see if the issue is still present regardless of style?

Sure! I totally forgot to do that last month!

Oh wait...

But sure, let's do a couple.

Here, for example, is plastique.

Mutilated by this setting:
screenshot from 2017-10-30 16-30-36

As it should be:
screenshot from 2017-10-30 16-08-40

Member

Frenzie commented Oct 30, 2017

You may also notice that in my screenshot the UI elements are not messed up, and consistently scale across monitors with different DPIs. This is why I'm led to believe that the issue you're seeing is due to the Qt style being used on your system. Can you try to force Qt to use a different style to see if the issue is still present regardless of style?

Sure! I totally forgot to do that last month!

Oh wait...

But sure, let's do a couple.

Here, for example, is plastique.

Mutilated by this setting:
screenshot from 2017-10-30 16-30-36

As it should be:
screenshot from 2017-10-30 16-08-40

@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Oct 30, 2017

Contributor

So why do the Qt blogs and docs say that's exactly what it's for?

This is what the Qt docs have to say about the attribute:

Qt::AA_EnableHighDpiScaling Enables high-DPI scaling in Qt on supported platforms (see also High DPI Displays). Supported platforms are X11, Windows and Android. Enabling makes Qt scale the main (device independent) coordinate system according to display scale factors provided by the operating system.

You say:

With this setting it's failing spectacularly at doing anything remotely like that, ftr.

As you can see from my screenshot, it's doing exactly what it claims to be doing. So the question is why it's not working correctly in your case.

Page doesn't load.

Sorry, forgot the TLD, fixed.

(Also, in your 200% and 300% scaling I have troubles understanding which is which.)

Contributor

Oblomov commented Oct 30, 2017

So why do the Qt blogs and docs say that's exactly what it's for?

This is what the Qt docs have to say about the attribute:

Qt::AA_EnableHighDpiScaling Enables high-DPI scaling in Qt on supported platforms (see also High DPI Displays). Supported platforms are X11, Windows and Android. Enabling makes Qt scale the main (device independent) coordinate system according to display scale factors provided by the operating system.

You say:

With this setting it's failing spectacularly at doing anything remotely like that, ftr.

As you can see from my screenshot, it's doing exactly what it claims to be doing. So the question is why it's not working correctly in your case.

Page doesn't load.

Sorry, forgot the TLD, fixed.

(Also, in your 200% and 300% scaling I have troubles understanding which is which.)

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

This is what the Qt docs have to say about the attribute:

Besides the blogs introducing the feature in the first place, that "(see also High DPI Displays)" links exactly to the page I quoted earlier.

  1. QT_AUTO_SCREEN​_SCALE_FACTOR is a stop-gap solution. "In the longer term, the application should be adapted to run unmodified." (Basic message that I've seen in the blogs and the docs.)
  2. "[Qt::AA_EnableHighDpiScaling] corresponds to setting the QT_AUTO_SCREEN​_SCALE_FACTOR environment variable to 1."
  3. "Otter is not an ancient app designed for low DPI values."

1, 2, 3 => This doesn't seem right.

As you can see from my screenshot, it's doing exactly what it claims to be doing. So the question is why it's not working correctly in your case.

That's impossible to tell from your screenshot. All I see is that what you would like it to do and what it's doing are the same thing. (Concretely, 1x on one monitor and 2x on the other.)

(Also, in your 200% and 300% scaling I have troubles understanding which is which.)

The better Otter is always on the right.

Any idea which package is behind this? Compiling in LiveUSB is a bit awkward.

cc -std=c99 -g -Wall -Wextra -DWITH_XCB=1 -Werror   xdpi.c  -lm -lX11 -lXrandr -lXinerama -lxcb -lxcb-randr -lxcb-xinerama -lxcb-xrm -o xdpi
xdpi.c:20:10: fatal error: xcb/xcb_xrm.h: No such file or directory
 #include <xcb/xcb_xrm.h>
          ^~~~~~~~~~~~~~~
compilation terminated.
Member

Frenzie commented Oct 30, 2017

This is what the Qt docs have to say about the attribute:

Besides the blogs introducing the feature in the first place, that "(see also High DPI Displays)" links exactly to the page I quoted earlier.

  1. QT_AUTO_SCREEN​_SCALE_FACTOR is a stop-gap solution. "In the longer term, the application should be adapted to run unmodified." (Basic message that I've seen in the blogs and the docs.)
  2. "[Qt::AA_EnableHighDpiScaling] corresponds to setting the QT_AUTO_SCREEN​_SCALE_FACTOR environment variable to 1."
  3. "Otter is not an ancient app designed for low DPI values."

1, 2, 3 => This doesn't seem right.

As you can see from my screenshot, it's doing exactly what it claims to be doing. So the question is why it's not working correctly in your case.

That's impossible to tell from your screenshot. All I see is that what you would like it to do and what it's doing are the same thing. (Concretely, 1x on one monitor and 2x on the other.)

(Also, in your 200% and 300% scaling I have troubles understanding which is which.)

The better Otter is always on the right.

Any idea which package is behind this? Compiling in LiveUSB is a bit awkward.

cc -std=c99 -g -Wall -Wextra -DWITH_XCB=1 -Werror   xdpi.c  -lm -lX11 -lXrandr -lXinerama -lxcb -lxcb-randr -lxcb-xinerama -lxcb-xrm -o xdpi
xdpi.c:20:10: fatal error: xcb/xcb_xrm.h: No such file or directory
 #include <xcb/xcb_xrm.h>
          ^~~~~~~~~~~~~~~
compilation terminated.
@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

Even a bunch of wildcards couldn't solve that one. Oh well, luckily you provided make xcb=0.

So this is how GNOME (in this case through Ubuntu) does things. I was expecting to potentially see something different from ye olde Xfce but apparently not.

100%

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 96
*** Done ***

200%

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 192
*** Done ***

300%

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 288
*** Done ***

I've also attached the compiled library for my own potential use.
xdpi.zip (LiveCD Ubuntu 17.10 build)

Edit: proper x64 binary with all options compiled on Debian Stretch.
xdpi.zip

Output on my primary OS (Debian Stretch x64 Xfce):

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 140
** xcb interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 140
*** Done ***
Member

Frenzie commented Oct 30, 2017

Even a bunch of wildcards couldn't solve that one. Oh well, luckily you provided make xcb=0.

So this is how GNOME (in this case through Ubuntu) does things. I was expecting to potentially see something different from ye olde Xfce but apparently not.

100%

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 96
*** Done ***

200%

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 192
*** Done ***

300%

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 288
*** Done ***

I've also attached the compiled library for my own potential use.
xdpi.zip (LiveCD Ubuntu 17.10 build)

Edit: proper x64 binary with all options compiled on Debian Stretch.
xdpi.zip

Output on my primary OS (Debian Stretch x64 Xfce):

$ ./xdpi 
*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 140
** xcb interfaces
Screen 0: 3840x2160 pixels, 1016x571 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		DisplayPort-0: 3840x2160 pixels, (U, connected) 527x296 mm: 185x185 dpi, 72x72 dpcm, dot pitch 0.14mm
Xinerama screens:
	0: 3840x2160 pixels, no dpi information
X resources:
	Xft.dpi: 140
*** Done ***
@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Oct 30, 2017

Contributor

So, in response to @Frenzie:

  1. re xdpi, the xcb backend is not necessary, it's there more as a didactic experience for me than for actual functionality, building with xcb=0 is perfectly fine and feature-complete, the results should be the same;
  2. re the settings vs the environment variable: the environment variable is a stopgap solution because legacy applications do not set the setting. Note that not all legacy applications behave correctly with the setting on, so it should only be used for applications that scale correctly;
  3. there seem to still be an issue in the Qt styling of some widget components when there is a mismatch between rendering and layout sizes, which is I guess what you are referring to in your screenshots; I remember reading about this somewhere in the Qt docs (basically due to the fact that some styling decisions are made statically on initializations and are thus not screen-dependent as they should be, and making them screen-dependent would require changes to the API.

The only real issue here is 3, which we can probably solve by going over the mismatching widget elements and unscaling them as appropriate.

Contributor

Oblomov commented Oct 30, 2017

So, in response to @Frenzie:

  1. re xdpi, the xcb backend is not necessary, it's there more as a didactic experience for me than for actual functionality, building with xcb=0 is perfectly fine and feature-complete, the results should be the same;
  2. re the settings vs the environment variable: the environment variable is a stopgap solution because legacy applications do not set the setting. Note that not all legacy applications behave correctly with the setting on, so it should only be used for applications that scale correctly;
  3. there seem to still be an issue in the Qt styling of some widget components when there is a mismatch between rendering and layout sizes, which is I guess what you are referring to in your screenshots; I remember reading about this somewhere in the Qt docs (basically due to the fact that some styling decisions are made statically on initializations and are thus not screen-dependent as they should be, and making them screen-dependent would require changes to the API.

The only real issue here is 3, which we can probably solve by going over the mismatching widget elements and unscaling them as appropriate.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 30, 2017

Member

Here's a messed up Windows screenshot for good measure. The too small Otter is, of course, with the setting enabled. :-)

virtualbox_word 2016 - win10_30_10_2017_20_34_39

Copying some stuff from the chat.

Anyway, my take on the problem at this point is basically as follows: some UX elements don't scale right (e.g., statusbar, various paddings). Using the environment variable/patch can smooth out some of these issues under the right circumstances.

If you want to try a virtual multi-monitor setup in VirtualBox you'll still have to turn them on in the View menu.

In Windows moving between differently scaled monitors does work better with that variable. But I stress that without it also works. It's just the already identified not properly behaving elements that don't play along. Doing more Linux tests would be more annoying (as I only have a few Windows virtual machines for regular use). But it does look like a stopgap measure to me because of its imperfections. A stopgap measure which works reasonably well on Windows and unfortunately doesn't work out very well on a common Linux setup.

tl;dr This is all very messy.

re the settings vs the environment variable: the environment variable is a stopgap solution because legacy applications do not set the setting. Note that not all legacy applications behave correctly with the setting on, so it should only be used for applications that scale correctly;

But what it explicitly says to do instead is these three action points:

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.

Not a peep about Qt::AA_EnableHighDpiScaling, which seems quite logical considering it's exactly the same as the environment variable. I'm getting the impression it's about porting over legacy apps with the least amount of trouble.

The only real issue here is 3, which we can probably solve by going over the mismatching widget elements and unscaling them as appropriate.

Funny, I see it exactly the other way around. The widgets are just a minor beauty flaw. The fundamentally incorrect scaling is the real issue.

Member

Frenzie commented Oct 30, 2017

Here's a messed up Windows screenshot for good measure. The too small Otter is, of course, with the setting enabled. :-)

virtualbox_word 2016 - win10_30_10_2017_20_34_39

Copying some stuff from the chat.

Anyway, my take on the problem at this point is basically as follows: some UX elements don't scale right (e.g., statusbar, various paddings). Using the environment variable/patch can smooth out some of these issues under the right circumstances.

If you want to try a virtual multi-monitor setup in VirtualBox you'll still have to turn them on in the View menu.

In Windows moving between differently scaled monitors does work better with that variable. But I stress that without it also works. It's just the already identified not properly behaving elements that don't play along. Doing more Linux tests would be more annoying (as I only have a few Windows virtual machines for regular use). But it does look like a stopgap measure to me because of its imperfections. A stopgap measure which works reasonably well on Windows and unfortunately doesn't work out very well on a common Linux setup.

tl;dr This is all very messy.

re the settings vs the environment variable: the environment variable is a stopgap solution because legacy applications do not set the setting. Note that not all legacy applications behave correctly with the setting on, so it should only be used for applications that scale correctly;

But what it explicitly says to do instead is these three action points:

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.

Not a peep about Qt::AA_EnableHighDpiScaling, which seems quite logical considering it's exactly the same as the environment variable. I'm getting the impression it's about porting over legacy apps with the least amount of trouble.

The only real issue here is 3, which we can probably solve by going over the mismatching widget elements and unscaling them as appropriate.

Funny, I see it exactly the other way around. The widgets are just a minor beauty flaw. The fundamentally incorrect scaling is the real issue.

@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Oct 31, 2017

Contributor

In Windows moving between differently scaled monitors does work better with that variable. But I stress that without it also works.

On Windows the situation is more complicated, because if an application doesn't declare HiDPI support, Windows itself bitmap-scales the application windows. OSX does the same. X11 doesn't. This means that legacy (completely DPI-unaware) applications “survive” better without proper DPI support on Windows (8+) and on OSX, but not on X11. And this matches my experience.

Not a peep about Qt::AA_EnableHighDpiScaling, which seems quite logical considering it's exactly the same as the environment variable. I'm getting the impression it's about porting over legacy apps with the least amount of trouble.

I would accept that explanation if not for the fact that without the setting, Qt widgets seem to be missing information about the per-screen DPI, which would be necessary for proper scaling across display resolutions.

Funny, I see it exactly the other way around. The widgets are just a minor beauty flaw. The fundamentally incorrect scaling is the real issue.

On my machine the experience is exactly the opposite. Without the setting, the overall rendering of the webpage is wrong, whereas with the setting the scaling follows the monitor DPI.

This is particularly evident with the webkit-ng backend, which uses the monitor DPI information to set the webpage device pixel ratio. Which backend are you using?

Guess which of these screenshots is with and which one is without the setting, on my HiDPI monitor with the font DPI set to high:

09:34
09:32

The main difference between my situations and yours seems to be that I'm not using a GTK DE/WM, whereas you are. Can you do your tests on Linux running on raw X11 or something like that?

Contributor

Oblomov commented Oct 31, 2017

In Windows moving between differently scaled monitors does work better with that variable. But I stress that without it also works.

On Windows the situation is more complicated, because if an application doesn't declare HiDPI support, Windows itself bitmap-scales the application windows. OSX does the same. X11 doesn't. This means that legacy (completely DPI-unaware) applications “survive” better without proper DPI support on Windows (8+) and on OSX, but not on X11. And this matches my experience.

Not a peep about Qt::AA_EnableHighDpiScaling, which seems quite logical considering it's exactly the same as the environment variable. I'm getting the impression it's about porting over legacy apps with the least amount of trouble.

I would accept that explanation if not for the fact that without the setting, Qt widgets seem to be missing information about the per-screen DPI, which would be necessary for proper scaling across display resolutions.

Funny, I see it exactly the other way around. The widgets are just a minor beauty flaw. The fundamentally incorrect scaling is the real issue.

On my machine the experience is exactly the opposite. Without the setting, the overall rendering of the webpage is wrong, whereas with the setting the scaling follows the monitor DPI.

This is particularly evident with the webkit-ng backend, which uses the monitor DPI information to set the webpage device pixel ratio. Which backend are you using?

Guess which of these screenshots is with and which one is without the setting, on my HiDPI monitor with the font DPI set to high:

09:34
09:32

The main difference between my situations and yours seems to be that I'm not using a GTK DE/WM, whereas you are. Can you do your tests on Linux running on raw X11 or something like that?

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 31, 2017

Member

On Windows the situation is more complicated, because if an application doesn't declare HiDPI support, Windows itself bitmap-scales the application windows.

You think I can't tell apart sharp and more pixelated, let alone fuzzy? ;-) The only time you see ugly bitmap-scaled stuff in Windows is with this setting. As the Qt docs say, this is a stopgap measure that "may incur some scaling or painting artifacts." Which is exactly what's happening.

Incidentally, as you're well aware we can also do that with xpra. Here's a nice wrapper script: https://github.com/kaueraal/run_scaled

This blog post suggests a Windows-specific workaround for proper DPI-scaling on that platform:

#ifdef Q_OS_WIN
    SetProcessDPIAware(); // call before the main event loop
#endif // Q_OS_WIN 

#if QT_VERSION >= QT_VERSION_CHECK(5,6,0)
    QApplication::setAttribute(Qt::AA_DisableHighDpiScaling);
#else
    qputenv("QT_DEVICE_PIXEL_RATIO", QByteArray("1"));
#endif // QT_VERSION

I would accept that explanation if not for the fact that without the setting, Qt widgets seem to be missing information about the per-screen DPI, which would be necessary for proper scaling across display resolutions.

I don't dispute that it's broken.

On my machine the experience is exactly the opposite. Without the setting, the overall rendering of the webpage is wrong, whereas with the setting the scaling follows the monitor DPI.

That problem is something about QtWebKit and viewport combined with zoom. It's also broken no matter what. It's just broken in different ways when QtWebKit sees another zoom level as the default.

Guess which of these screenshots is with and which one is without the setting, on my HiDPI monitor with the font DPI set to high:

It's obvious that the first one is ugly and broken (i.e., with this setting). :-)

The main difference between my situations and yours seems to be that I'm not using a GTK DE/WM, whereas you are. Can you do your tests on Linux running on raw X11 or something like that?

My primary point is that "my" situation is not a niche situation. If I were running something niche like "raw X11" (of course I'd be using xmonad or something, not actually raw X11) then this entire series of posts would be more exploratory than argumentative.

Of course I'm curious regardless, so I might look into setting up another few VMs.

Member

Frenzie commented Oct 31, 2017

On Windows the situation is more complicated, because if an application doesn't declare HiDPI support, Windows itself bitmap-scales the application windows.

You think I can't tell apart sharp and more pixelated, let alone fuzzy? ;-) The only time you see ugly bitmap-scaled stuff in Windows is with this setting. As the Qt docs say, this is a stopgap measure that "may incur some scaling or painting artifacts." Which is exactly what's happening.

Incidentally, as you're well aware we can also do that with xpra. Here's a nice wrapper script: https://github.com/kaueraal/run_scaled

This blog post suggests a Windows-specific workaround for proper DPI-scaling on that platform:

#ifdef Q_OS_WIN
    SetProcessDPIAware(); // call before the main event loop
#endif // Q_OS_WIN 

#if QT_VERSION >= QT_VERSION_CHECK(5,6,0)
    QApplication::setAttribute(Qt::AA_DisableHighDpiScaling);
#else
    qputenv("QT_DEVICE_PIXEL_RATIO", QByteArray("1"));
#endif // QT_VERSION

I would accept that explanation if not for the fact that without the setting, Qt widgets seem to be missing information about the per-screen DPI, which would be necessary for proper scaling across display resolutions.

I don't dispute that it's broken.

On my machine the experience is exactly the opposite. Without the setting, the overall rendering of the webpage is wrong, whereas with the setting the scaling follows the monitor DPI.

That problem is something about QtWebKit and viewport combined with zoom. It's also broken no matter what. It's just broken in different ways when QtWebKit sees another zoom level as the default.

Guess which of these screenshots is with and which one is without the setting, on my HiDPI monitor with the font DPI set to high:

It's obvious that the first one is ugly and broken (i.e., with this setting). :-)

The main difference between my situations and yours seems to be that I'm not using a GTK DE/WM, whereas you are. Can you do your tests on Linux running on raw X11 or something like that?

My primary point is that "my" situation is not a niche situation. If I were running something niche like "raw X11" (of course I'd be using xmonad or something, not actually raw X11) then this entire series of posts would be more exploratory than argumentative.

Of course I'm curious regardless, so I might look into setting up another few VMs.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 31, 2017

Member

This one's fun too.

screenshot_2017-10-31_15-45-46

But yeah, my objection is invalid in the sense that there's no easy way[1] to get any kind of correct behavior out of this on Ubuntu. For example, dragging an app from reasonable DPI to low DPI and back works out okay (for some GTK apps, anyway), but observe this beaut from starting an app in low DPI and dragging it to reasonable DPI ("200%").

screenshot_2017-10-31_15-52-42

I did find this ancient blog post that suggests that on Windows and X11 this is the way to go.
https://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/

Case II: Qt supports the scaling and computes a scale factor.

Supported platforms: X11, Windows, Android, Eglfs

Qt can enable devicePixelRatio scaling on platforms that do not support it natively. This can be done via an environment variable or an application attribute in the application source code:

QT_AUTO_SCREEN_SCALE_FACTOR=1 ./myApp

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Qt will then query the the operating system for display metrics using native API, or in the eglfs case fall back on QT_QPA_EGLFS_PHYSICAL_WIDTH, QT_QPA_EGLFS_PHYSICAL_HEIGHT and the display pixel size.

Note that supposedly in Wayland it's all good: https://blog.qt.io/blog/2015/01/27/qt-weekly-24-high-dpi-qtwayland/

[1] Defined as pulling some sensible GUI config toggles, even if I might often personally find xorg.conf friendlier.

Edit: hm, so this is what happens on the virtual machine:

*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3576x1652 pixels, 946x437 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		XWAYLAND0: 1360x772 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
		XWAYLAND1: 2216x1652 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
Xinerama screens:
	0: 1360x772 pixels, no dpi information
	1: 2216x1652 pixels, no dpi information
X resources:
	Xft.dpi: 96
** xcb interfaces
Screen 0: 3576x1652 pixels, 946x437 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		XWAYLAND0: 1360x772 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
		XWAYLAND1: 2216x1652 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
Xinerama screens:
	0: 1360x772 pixels, no dpi information
	1: 2216x1652 pixels, no dpi information
X resources:
	Xft.dpi: 96
*** Done ***
Member

Frenzie commented Oct 31, 2017

This one's fun too.

screenshot_2017-10-31_15-45-46

But yeah, my objection is invalid in the sense that there's no easy way[1] to get any kind of correct behavior out of this on Ubuntu. For example, dragging an app from reasonable DPI to low DPI and back works out okay (for some GTK apps, anyway), but observe this beaut from starting an app in low DPI and dragging it to reasonable DPI ("200%").

screenshot_2017-10-31_15-52-42

I did find this ancient blog post that suggests that on Windows and X11 this is the way to go.
https://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/

Case II: Qt supports the scaling and computes a scale factor.

Supported platforms: X11, Windows, Android, Eglfs

Qt can enable devicePixelRatio scaling on platforms that do not support it natively. This can be done via an environment variable or an application attribute in the application source code:

QT_AUTO_SCREEN_SCALE_FACTOR=1 ./myApp

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Qt will then query the the operating system for display metrics using native API, or in the eglfs case fall back on QT_QPA_EGLFS_PHYSICAL_WIDTH, QT_QPA_EGLFS_PHYSICAL_HEIGHT and the display pixel size.

Note that supposedly in Wayland it's all good: https://blog.qt.io/blog/2015/01/27/qt-weekly-24-high-dpi-qtwayland/

[1] Defined as pulling some sensible GUI config toggles, even if I might often personally find xorg.conf friendlier.

Edit: hm, so this is what happens on the virtual machine:

*** Resolution and dot pitch information exposed by X11 ***
** Xlib interfaces
Screen 0: 3576x1652 pixels, 946x437 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		XWAYLAND0: 1360x772 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
		XWAYLAND1: 2216x1652 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
Xinerama screens:
	0: 1360x772 pixels, no dpi information
	1: 2216x1652 pixels, no dpi information
X resources:
	Xft.dpi: 96
** xcb interfaces
Screen 0: 3576x1652 pixels, 946x437 mm: 96x96 dpi, 37x37 dpcm, dot pitch 0.26mm
	XRandR:
		XWAYLAND0: 1360x772 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
		XWAYLAND1: 2216x1652 pixels, (U, connected) 0x0 mm: 0x0 dpi, 0x0 dpcm, dot pitch 0mm
Xinerama screens:
	0: 1360x772 pixels, no dpi information
	1: 2216x1652 pixels, no dpi information
X resources:
	Xft.dpi: 96
*** Done ***
@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 31, 2017

Member

Okay, there is a way to get reasonable-ish behavior out of this on Ubuntu 17.10.

First install the Qt Wayland plugin.

sudo apt install qtwayland5

Then start Otter with the -platform wayland switch.

Unfortunately this is not a panacea as it's fuzzy and QT_AUTO_SCREEN_SCALE_FACTOR=1 makes no difference. But as far as dragging it back and forth between the different screens and automatic rescaling goes it's a winner. It comes closest to what I've seen on Windows (in not-Otter).

Member

Frenzie commented Oct 31, 2017

Okay, there is a way to get reasonable-ish behavior out of this on Ubuntu 17.10.

First install the Qt Wayland plugin.

sudo apt install qtwayland5

Then start Otter with the -platform wayland switch.

Unfortunately this is not a panacea as it's fuzzy and QT_AUTO_SCREEN_SCALE_FACTOR=1 makes no difference. But as far as dragging it back and forth between the different screens and automatic rescaling goes it's a winner. It comes closest to what I've seen on Windows (in not-Otter).

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 31, 2017

Member

@Oblomov

Results are the same in plain X (with Fusion, etc.), assuming these are the kind of commands you have in mind:

startx ./otter-stuff
QT_AUTO_SCREEN_SCALE_FACTOR=1 startx ./otter-stuff`

Not sure how to take screenshots.

Anyway, you can very simply replicate everything from the above by using, e.g., -- -dpi=144

startx ./otter-stuff -- -dpi=144
QT_AUTO_SCREEN_SCALE_FACTOR=1 startx ./otter-stuff -- -dpi=144

Of course you'll say that's just the Xft.dpi and per-monitor DPI. I suppose one could set a fake DisplaySize in xorg.conf or something like that, but in spite of that I'm seeing things like "X11 doesn't support multiple DPIs at all" (source).

Incidentally, I came across this GNOME blog proclaiming they have surpassed some X11 deficiencies: https://blogs.gnome.org/mclasen/2017/05/19/fractional-scaling-goes-east/

The Arch Wiki has some interesting stuff: https://wiki.archlinux.org/index.php/HiDPI#Side_display

Perhaps there is no such thing as a right approach, but I since these sizing issues only affect a few select elements I remain convinced they should be fixed regardless of this setting.

screenshot_2017-10-31_18-14-46

Consider (scaled at "2x" even though imo that is much too large for illustrative purposes):

Ye olde Qt Skype: minor beauty flaws only (not unlike Otter, some hardcoded pixel values or something).

screenshot_2017-10-31_18-18-28

qBittorrent scaled normally by DPI: beautiful (but with clear minor flaws such as the search box)

screenshot_2017-10-31_18-18-56

qBittorrent scaled with this setting: horrendous (overall significantly worse but some minor issues compensated for)

screenshot_2017-10-31_18-19-41

It seems to me that Otter should strive to be like qBittorrent by default because it works the way people expect it to without ugly visual glitches. Whatever causes those, it's a problem just as much on Windows as it is on Linux.

PS Also of interest: http://swaywm.org/ http://way-cooler.org/

Member

Frenzie commented Oct 31, 2017

@Oblomov

Results are the same in plain X (with Fusion, etc.), assuming these are the kind of commands you have in mind:

startx ./otter-stuff
QT_AUTO_SCREEN_SCALE_FACTOR=1 startx ./otter-stuff`

Not sure how to take screenshots.

Anyway, you can very simply replicate everything from the above by using, e.g., -- -dpi=144

startx ./otter-stuff -- -dpi=144
QT_AUTO_SCREEN_SCALE_FACTOR=1 startx ./otter-stuff -- -dpi=144

Of course you'll say that's just the Xft.dpi and per-monitor DPI. I suppose one could set a fake DisplaySize in xorg.conf or something like that, but in spite of that I'm seeing things like "X11 doesn't support multiple DPIs at all" (source).

Incidentally, I came across this GNOME blog proclaiming they have surpassed some X11 deficiencies: https://blogs.gnome.org/mclasen/2017/05/19/fractional-scaling-goes-east/

The Arch Wiki has some interesting stuff: https://wiki.archlinux.org/index.php/HiDPI#Side_display

Perhaps there is no such thing as a right approach, but I since these sizing issues only affect a few select elements I remain convinced they should be fixed regardless of this setting.

screenshot_2017-10-31_18-14-46

Consider (scaled at "2x" even though imo that is much too large for illustrative purposes):

Ye olde Qt Skype: minor beauty flaws only (not unlike Otter, some hardcoded pixel values or something).

screenshot_2017-10-31_18-18-28

qBittorrent scaled normally by DPI: beautiful (but with clear minor flaws such as the search box)

screenshot_2017-10-31_18-18-56

qBittorrent scaled with this setting: horrendous (overall significantly worse but some minor issues compensated for)

screenshot_2017-10-31_18-19-41

It seems to me that Otter should strive to be like qBittorrent by default because it works the way people expect it to without ugly visual glitches. Whatever causes those, it's a problem just as much on Windows as it is on Linux.

PS Also of interest: http://swaywm.org/ http://way-cooler.org/

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Oct 31, 2017

Member

Attaching a compiled binary of qtdpi for convenience.

qtdpi-qt-5.7.1-x86_64.zip

Output on my main computer:

$ ./qtdpi 
QT version: 0x50701
Enable/Disable: 0/0
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 185.215
		 Logical DPI: 140
		 pixel ratio: 1
Enable/Disable: 0/1
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 185.215
		 Logical DPI: 140
		 pixel ratio: 1
Enable/Disable: 1/0
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 92.6073
		 Logical DPI: 70
		 pixel ratio: 2
Enable/Disable: 1/1
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 185.215
		 Logical DPI: 140
		 pixel ratio: 1
Member

Frenzie commented Oct 31, 2017

Attaching a compiled binary of qtdpi for convenience.

qtdpi-qt-5.7.1-x86_64.zip

Output on my main computer:

$ ./qtdpi 
QT version: 0x50701
Enable/Disable: 0/0
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 185.215
		 Logical DPI: 140
		 pixel ratio: 1
Enable/Disable: 0/1
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 185.215
		 Logical DPI: 140
		 pixel ratio: 1
Enable/Disable: 1/0
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 92.6073
		 Logical DPI: 70
		 pixel ratio: 2
Enable/Disable: 1/1
Global pixel ratio: 1
Screens: 1
	DisplayPort-0:
		Physical DPI: 185.215
		 Logical DPI: 140
		 pixel ratio: 1
@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 1, 2017

Member

@Oblomov Output from Windows. Since I installed the open source Qt Creator the other day and your Qt program doesn't require anything else it set up mingw32 automatically.

QT version: 0x50902
Enable/Disable: 0/0
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 96.0004
		 Logical DPI: 192
		 pixel ratio: 1
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 120
		 pixel ratio: 1
Enable/Disable: 0/1
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 96.0004
		 Logical DPI: 192
		 pixel ratio: 1
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 120
		 pixel ratio: 1
Enable/Disable: 1/0
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 48.0121
		 Logical DPI: 96
		 pixel ratio: 2
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
Enable/Disable: 1/1
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 96.0004
		 Logical DPI: 192
		 pixel ratio: 1
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 120
		 pixel ratio: 1
Member

Frenzie commented Nov 1, 2017

@Oblomov Output from Windows. Since I installed the open source Qt Creator the other day and your Qt program doesn't require anything else it set up mingw32 automatically.

QT version: 0x50902
Enable/Disable: 0/0
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 96.0004
		 Logical DPI: 192
		 pixel ratio: 1
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 120
		 pixel ratio: 1
Enable/Disable: 0/1
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 96.0004
		 Logical DPI: 192
		 pixel ratio: 1
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 120
		 pixel ratio: 1
Enable/Disable: 1/0
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 48.0121
		 Logical DPI: 96
		 pixel ratio: 2
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
Enable/Disable: 1/1
Global pixel ratio: 1
Screens: 3
	\\.\DISPLAY1:
		Physical DPI: 96.0004
		 Logical DPI: 192
		 pixel ratio: 1
	\\.\DISPLAY2:
		Physical DPI: 96.0355
		 Logical DPI: 96
		 pixel ratio: 1
	\\.\DISPLAY3:
		Physical DPI: 96.0355
		 Logical DPI: 120
		 pixel ratio: 1
@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Nov 1, 2017

Contributor

The statement “X11 does not support multiple DPIs at all” is wrong. X11 supports multiple DPIs both in the old-style “separate X Screens” case (where the different DPI is reported per-Screen from the core protocol) and in the modern RANDR world (where the DPI of each monitor/output is reported by RANDR).

The difference between X11 and things such as Windows 8+ and Mac OS X is that DPI scaling is entirely the client responsibility, and the protocol has no core/default way to specify a (cross-client) “device pixel ratio”, neither per-monitor nor globally. This is actually similar to the situation in older Windows versions, and Windows 8+ if the application doesn't declare DPI support.

For X11, the GTK devs have come out with a draft specification that might handle this, as part of their XSETTINGS framework, but it's an impressively unclear and incomplete specification which nothing outside of GTK uses. And as with anything GTK, there is no guarantee that the behavior of any specific setting is preserved even across minor versions (one of the “advantages” of there not being a clear, well-defined specification).

What this setting does is to compute the device pixel ratio from the physical DPI of each output, as you can see from the qtdpi output when comparing the 1/0 output with the others. This is essential for proper mixed DPI support when dealing with configurations where the environment does not provide the information (such as Windows < 8, Windows 8+ when the application does not declare HiDPI support, or under X11).

I agree with you that the visual glitches should be compensated for regardless of this settings, and that Otter should strive for DPI-independence globally. Ideally, it should render the same regardless of whether this setting is on or not. The underlying issue is that on Linux we want to have proper per-output values for devicePixelRatio(), and the only way to get this information is with this settings on in X11. Without this settings, things such as qtwebkit-ng simply cannot get the information they need to automatically adapt their own devicePixelRatio to different outputs. And this really isn't something that the library can fix by itself.

We might have to differentiate the behavior depending on the operating system. If the environment has a way to properly communicate per-output DPIs, we should enable that and not this flag. If the environment does not, we should enable this flag and thus gain proper support for per-output DPIs in these environments as well.

Contributor

Oblomov commented Nov 1, 2017

The statement “X11 does not support multiple DPIs at all” is wrong. X11 supports multiple DPIs both in the old-style “separate X Screens” case (where the different DPI is reported per-Screen from the core protocol) and in the modern RANDR world (where the DPI of each monitor/output is reported by RANDR).

The difference between X11 and things such as Windows 8+ and Mac OS X is that DPI scaling is entirely the client responsibility, and the protocol has no core/default way to specify a (cross-client) “device pixel ratio”, neither per-monitor nor globally. This is actually similar to the situation in older Windows versions, and Windows 8+ if the application doesn't declare DPI support.

For X11, the GTK devs have come out with a draft specification that might handle this, as part of their XSETTINGS framework, but it's an impressively unclear and incomplete specification which nothing outside of GTK uses. And as with anything GTK, there is no guarantee that the behavior of any specific setting is preserved even across minor versions (one of the “advantages” of there not being a clear, well-defined specification).

What this setting does is to compute the device pixel ratio from the physical DPI of each output, as you can see from the qtdpi output when comparing the 1/0 output with the others. This is essential for proper mixed DPI support when dealing with configurations where the environment does not provide the information (such as Windows < 8, Windows 8+ when the application does not declare HiDPI support, or under X11).

I agree with you that the visual glitches should be compensated for regardless of this settings, and that Otter should strive for DPI-independence globally. Ideally, it should render the same regardless of whether this setting is on or not. The underlying issue is that on Linux we want to have proper per-output values for devicePixelRatio(), and the only way to get this information is with this settings on in X11. Without this settings, things such as qtwebkit-ng simply cannot get the information they need to automatically adapt their own devicePixelRatio to different outputs. And this really isn't something that the library can fix by itself.

We might have to differentiate the behavior depending on the operating system. If the environment has a way to properly communicate per-output DPIs, we should enable that and not this flag. If the environment does not, we should enable this flag and thus gain proper support for per-output DPIs in these environments as well.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 1, 2017

Member

I propose to make this a setting under Advanced → Appearance if feasible. (Perhaps limited to about:config on, say, Mac OS). It's more logical and intuitively discoverable that way, as opposed to passing QT_AUTO_SCREEN_SCALE_FACTOR= or QT_AUTO_SCREEN_SCALE_FACTOR=1 respectively.

Because Qt scaling is overall superior and more correct without this on, I remain opposed to enabling it by default. At the same time it certainly has its uses, such as automatically providing a hopefully better default zoom level and viewport in QtWebKit and mixed DPI setups on X11.

Overriding this with environment variables is unfriendly, but with the situation as broken as it is, it's clear that both options need to be easily accessible.

Member

Frenzie commented Nov 1, 2017

I propose to make this a setting under Advanced → Appearance if feasible. (Perhaps limited to about:config on, say, Mac OS). It's more logical and intuitively discoverable that way, as opposed to passing QT_AUTO_SCREEN_SCALE_FACTOR= or QT_AUTO_SCREEN_SCALE_FACTOR=1 respectively.

Because Qt scaling is overall superior and more correct without this on, I remain opposed to enabling it by default. At the same time it certainly has its uses, such as automatically providing a hopefully better default zoom level and viewport in QtWebKit and mixed DPI setups on X11.

Overriding this with environment variables is unfriendly, but with the situation as broken as it is, it's clear that both options need to be easily accessible.

@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Nov 1, 2017

Contributor

I'm a big fan of options, so yes, that could be one way to do it. Of course, ideally the proper fix should be in Qt itself rather than in Otter.

From our analysis of the situation, it seems that while on Windows Qt sets the logical DPI according to what Windows reports, and keeps device pixel ratio 1, on Linux Qt has a single logical DPI (at least per X Screen), computed from Xft.dpi and with fallback on the core DPI, and the auto screen scale factor changes the device pixel ratio.

A possible solution that would reconcile your perception and mine would be if the automatic screen scaling under X11 was done by changing the logical DPI instead of the device pixel ratio: basically, if Qt had an option to set a per-output logical DPI in X11, computed from the global logical DPI, prorated with the physical DPI of the displays, it would then be possible to have per-monitor UI scaling in a Windows-like fashion. I'll see if I can bring this up with the Qt devs.

The remaining issue would be that qtwebkit-ng uses the devicePixelRatio rather than the logical DPI to determine the CSS device pixel ratio. We can discuss this with @annulen and see if it's possible to use both.

Contributor

Oblomov commented Nov 1, 2017

I'm a big fan of options, so yes, that could be one way to do it. Of course, ideally the proper fix should be in Qt itself rather than in Otter.

From our analysis of the situation, it seems that while on Windows Qt sets the logical DPI according to what Windows reports, and keeps device pixel ratio 1, on Linux Qt has a single logical DPI (at least per X Screen), computed from Xft.dpi and with fallback on the core DPI, and the auto screen scale factor changes the device pixel ratio.

A possible solution that would reconcile your perception and mine would be if the automatic screen scaling under X11 was done by changing the logical DPI instead of the device pixel ratio: basically, if Qt had an option to set a per-output logical DPI in X11, computed from the global logical DPI, prorated with the physical DPI of the displays, it would then be possible to have per-monitor UI scaling in a Windows-like fashion. I'll see if I can bring this up with the Qt devs.

The remaining issue would be that qtwebkit-ng uses the devicePixelRatio rather than the logical DPI to determine the CSS device pixel ratio. We can discuss this with @annulen and see if it's possible to use both.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 1, 2017

Member

Screenshot for @Emdek of too large window decorations on Windows 10, allegedly fixed in Qt 5.9 but clearly not (Otter is on 5.9.1 on Windows) https://bugreports.qt.io/browse/QTBUG-53255

virtualbox_word 2016 - win10_01_11_2017_16_16_26

Also you can see some odd sizing issues on the left in this screenshot, which is without. I interpreted this as not sizing correctly yesterday, but as it turns out those UI elements (but not all of them, or even every part of every element) take their DPI from the primary display.

That means that on Windows things are better with this setting enabled if you have a mixed DPI multi-monitor setup.

The titlebar size, by contrast, is simply taken from the monitor with the highest DPI, regardless of which display is primary or secondary. This Qt bug is unaffected by the setting in question.

PS

This is what it looks like when Windows draws the window decorations and bitmap scales the window contents:

screenshot_2017-11-01_16-41-38

I was checking up on VLC because afaik it uses Qt, but either it doesn't on Windows or it uses an older version or something. It doesn't do any proper scaling with or without. It doesn't respond to the windows scaling setting either. It's telling Windows that it can scale properly, but doesn't.

@Oblomov

A possible solution that would reconcile your perception and mine would be if the automatic screen scaling under X11 was done by changing the logical DPI instead of the device pixel ratio: basically, if Qt had an option to set a per-output logical DPI in X11, computed from the global logical DPI, prorated with the physical DPI of the displays, it would then be possible to have per-monitor UI scaling in a Windows-like fashion. I'll see if I can bring this up with the Qt devs.

That would definitely help. The device DPI is, to put it bluntly, almost utterly irrelevant in my perception except as a hopefully reasonable default. Your suggestion to change the font size doesn't cut it, because that only affects the font size (no surprise there :-P), which leaves you with massively over or undersized UI elements depending on your preferences and visual acuity. The only problem is that the setting to properly affect this happens to be historically called "DPI", which is something both Windows and KDE solved by simply renaming it "scaling" while doing essentially the exact same thing under the hood. Except with per-monitor handling added, which is still a WIP on KDE.

I'm really not sure why it took until Windows 8 to do that. I had 86 PPI (1280x1024 on 19") next to 125 PPI (1400x1050 on 14") and 118 PPI (1600x1200 on 17") over ten years ago. It was close enough to each other in density to be workable, but definitely jarring. I missed out on 1980x1200, and then we entered the dark ages of pitiful vertically challenged resolutions and meager pixel densities for half a decade before I was able to acquire my UHD monitor in early 2015.

Member

Frenzie commented Nov 1, 2017

Screenshot for @Emdek of too large window decorations on Windows 10, allegedly fixed in Qt 5.9 but clearly not (Otter is on 5.9.1 on Windows) https://bugreports.qt.io/browse/QTBUG-53255

virtualbox_word 2016 - win10_01_11_2017_16_16_26

Also you can see some odd sizing issues on the left in this screenshot, which is without. I interpreted this as not sizing correctly yesterday, but as it turns out those UI elements (but not all of them, or even every part of every element) take their DPI from the primary display.

That means that on Windows things are better with this setting enabled if you have a mixed DPI multi-monitor setup.

The titlebar size, by contrast, is simply taken from the monitor with the highest DPI, regardless of which display is primary or secondary. This Qt bug is unaffected by the setting in question.

PS

This is what it looks like when Windows draws the window decorations and bitmap scales the window contents:

screenshot_2017-11-01_16-41-38

I was checking up on VLC because afaik it uses Qt, but either it doesn't on Windows or it uses an older version or something. It doesn't do any proper scaling with or without. It doesn't respond to the windows scaling setting either. It's telling Windows that it can scale properly, but doesn't.

@Oblomov

A possible solution that would reconcile your perception and mine would be if the automatic screen scaling under X11 was done by changing the logical DPI instead of the device pixel ratio: basically, if Qt had an option to set a per-output logical DPI in X11, computed from the global logical DPI, prorated with the physical DPI of the displays, it would then be possible to have per-monitor UI scaling in a Windows-like fashion. I'll see if I can bring this up with the Qt devs.

That would definitely help. The device DPI is, to put it bluntly, almost utterly irrelevant in my perception except as a hopefully reasonable default. Your suggestion to change the font size doesn't cut it, because that only affects the font size (no surprise there :-P), which leaves you with massively over or undersized UI elements depending on your preferences and visual acuity. The only problem is that the setting to properly affect this happens to be historically called "DPI", which is something both Windows and KDE solved by simply renaming it "scaling" while doing essentially the exact same thing under the hood. Except with per-monitor handling added, which is still a WIP on KDE.

I'm really not sure why it took until Windows 8 to do that. I had 86 PPI (1280x1024 on 19") next to 125 PPI (1400x1050 on 14") and 118 PPI (1600x1200 on 17") over ten years ago. It was close enough to each other in density to be workable, but definitely jarring. I missed out on 1980x1200, and then we entered the dark ages of pitiful vertically challenged resolutions and meager pixel densities for half a decade before I was able to acquire my UHD monitor in early 2015.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 2, 2017

Member

@Oblomov Well, here's something curious. @Emdek tells me he's 99% sure he generated weekly 200 after merging this. But, in the AppImage:

Plain AppImage

screenshot_2017-11-02_13-05-20

QT_AUTO_SCREEN_SCALE_FACTOR=1 AppImage

screenshot_2017-11-02_13-04-59

You can see the plain AppImage is broken (i.e., too small) as it has been for the past few weeks. This doesn't happen when I compile Otter myself. But even more curiously, it looks like this setting doesn't make a difference in the AppImage? I'll await new AppImage builds; perhaps @Emdek was mistaken. :-P

(Also note how in the AppImage the menu text and the sidebar don't scale either way.)

Update: same on (Pre) RC2.

Member

Frenzie commented Nov 2, 2017

@Oblomov Well, here's something curious. @Emdek tells me he's 99% sure he generated weekly 200 after merging this. But, in the AppImage:

Plain AppImage

screenshot_2017-11-02_13-05-20

QT_AUTO_SCREEN_SCALE_FACTOR=1 AppImage

screenshot_2017-11-02_13-04-59

You can see the plain AppImage is broken (i.e., too small) as it has been for the past few weeks. This doesn't happen when I compile Otter myself. But even more curiously, it looks like this setting doesn't make a difference in the AppImage? I'll await new AppImage builds; perhaps @Emdek was mistaken. :-P

(Also note how in the AppImage the menu text and the sidebar don't scale either way.)

Update: same on (Pre) RC2.

@Oblomov

This comment has been minimized.

Show comment
Hide comment
@Oblomov

Oblomov Nov 2, 2017

Contributor

If the AppImage is built against Qt < 5.9, the setting is not enabled.

Contributor

Oblomov commented Nov 2, 2017

If the AppImage is built against Qt < 5.9, the setting is not enabled.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 2, 2017

Member

@Oblomov But that's the thing: it's 5.10.

Member

Frenzie commented Nov 2, 2017

@Oblomov But that's the thing: it's 5.10.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 3, 2017

Member

Adding some XP screens. This is at Qt 5.6, which explains why it's in some ways worse than I'd expect. (It's unrelated to this PR as such but I figured I might as well document it.)

At 120 DPI.

virtualbox_ie8 - winxp_03_11_2017_18_31_26
virtualbox_ie8 - winxp_03_11_2017_18_34_42

QT_AUTO_SCREEN_SCALE_FACTOR=1

virtualbox_ie8 - winxp_03_11_2017_18_45_47

At "200%" (192 DPI)

virtualbox_ie8 - winxp_03_11_2017_18_40_59

QT_AUTO_SCREEN_SCALE_FACTOR=1

virtualbox_ie8 - winxp_03_11_2017_18_43_47

Member

Frenzie commented Nov 3, 2017

Adding some XP screens. This is at Qt 5.6, which explains why it's in some ways worse than I'd expect. (It's unrelated to this PR as such but I figured I might as well document it.)

At 120 DPI.

virtualbox_ie8 - winxp_03_11_2017_18_31_26
virtualbox_ie8 - winxp_03_11_2017_18_34_42

QT_AUTO_SCREEN_SCALE_FACTOR=1

virtualbox_ie8 - winxp_03_11_2017_18_45_47

At "200%" (192 DPI)

virtualbox_ie8 - winxp_03_11_2017_18_40_59

QT_AUTO_SCREEN_SCALE_FACTOR=1

virtualbox_ie8 - winxp_03_11_2017_18_43_47

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 3, 2017

Member

Windows 7 has some pretty terrible effects with this patch, unlike anything I've seen on XP (where it's good) or 8+ (where it's at least reasonable).

150%

win-7-scaling-broken

I'm posting from the VM here, so another post will be coming soon.

Member

Frenzie commented Nov 3, 2017

Windows 7 has some pretty terrible effects with this patch, unlike anything I've seen on XP (where it's good) or 8+ (where it's at least reasonable).

150%

win-7-scaling-broken

I'm posting from the VM here, so another post will be coming soon.

@Frenzie

This comment has been minimized.

Show comment
Hide comment
@Frenzie

Frenzie Nov 3, 2017

Member

200%

Interestingly, this isn't nearly as bad. Clearly these issues are similar to what I dislike on my Linux box and on Windows 10, except on Windows 10 it more consistently makes everything too large.

otter-200-windows-7

Member

Frenzie commented Nov 3, 2017

200%

Interestingly, this isn't nearly as bad. Clearly these issues are similar to what I dislike on my Linux box and on Windows 10, except on Windows 10 it more consistently makes everything too large.

otter-200-windows-7

@trollixx trollixx referenced this pull request Jan 17, 2018

Open

Wrong UI scaling #869

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment