Skip to content
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

DPI Awareness/Scaling Issues (Win10) #800

Closed
vadi2 opened this issue Mar 31, 2017 · 35 comments · Fixed by #2172
Closed

DPI Awareness/Scaling Issues (Win10) #800

vadi2 opened this issue Mar 31, 2017 · 35 comments · Fixed by #2172
Milestone

Comments

@vadi2
Copy link
Member

vadi2 commented Mar 31, 2017

Summary:
Mudlet exhibits behavior associated with static size values (in pixels) in the Qt GUI widgets rather than using relative values. Additionally, the application does not specify DPI awareness such that Qt autoscales the application using the native Windows display APIs.* As such, the UI is, while usable, not properly rendered which breaks third-party UI add-ons produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the "right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for one of the following:

The addition of a qt.conf directive to specify an equivalent of the following (passed at runtime, instructs Windows to treat the application as non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

The addition of the following property setter for Windows builds to achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft Surface or 4K display with scaling enabled and set to a value other than 100%. Observe the UI scaling issues in the splash frame and Connections frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's working with Mudlet3-iota built against Qt5.6 on Windows 10 following the wiki instructions. I am building and testing the second (probably preferable) fix.

Launchpad Details: #LP1652413 Colin Gannon - 2016-12-24 01:38:31 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Could you attach screenshots? I don't think any developers have a 4K
display.

On Sat, 24 Dec 2016 11:45 am Colin Gannon, wrote:

Public bug reported:

Summary:
Mudlet exhibits behavior associated with static size values (in pixels) in
the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

The addition of a qt.conf directive to specify an equivalent of the
following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

The addition of the following property setter for Windows builds to
achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

** Affects: mudlet
Importance: Undecided
Status: New

** Tags: gui

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

Launchpad Details: #LPC Vadim Peretokin - 2016-12-24 02:26:40 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Sure - just uploaded screenshots of the Sessions screen as an example. You can see the scaling issue where text is being cut off and form fields are generally smaller/too short. This is evident throughout the app and totally messes up Geyser elements.

This may be easily fixed by passing the following option to ./mudlet.exe:
-platform windows:dpiawareness=0

OR via the creation of an ini-style qt.conf file in the Mudlet directory (default: C:\Program Files (x86)\mudlet-3.0.0-iota) with the following contents:
[Platforms]
WindowsArguments = dpiawareness=0

This tells Qt to let Windows know the app doesn't know how to scale if given a non-standard DPI ratio and lets windows automagically scale the app.

The former solution is probably best. I tried re-building Mudlet with the AA_EnableHighDpiScaling attribute set, but I can't find the proper spot (QApplication constructor?) in order to set the attribute. The qt.conf solution also did the trick easily enough and isn't too hacky so I didn't continue investigating.

Launchpad Details: #LPC Colin Gannon - 2016-12-25 19:10:16 +0000

Edited: 2018/01/25 by SlySven to include images from original Luanchpad topic:
Windows thinks Mudlet is DPI-aware and does not scale (issue):

dpi_aware

Mudlet with qt.conf to turn off dpi-awareness and let Windows handle scaling.:
hidpi_naive

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Hm... I don't like how either look, though setting up the autoscaling
option would be good for 3.0 so it's at least usable on a HiDPI display. I
wonder why does it break so much with scaling off though - shouldn't the
only thing that look bad are the images we use?

On Mon, Dec 26, 2016 at 5:20 AM Colin Gannon wrote:

** Attachment added: "Mudlet with qt.conf to turn off dpi-awareness and
let Windows handle scaling."

https://bugs.launchpad.net/mudlet/+bug/1652413/+attachment/4796366/+files/hidpi_naive.PNG

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

Launchpad Details: #LPC Vadim Peretokin - 2016-12-26 03:40:27 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Agreed. I've experimented a little further as Qt offers a bunch of ways to handle this.

Solution A: Set QT_AUTO_SCREEN_SCALE_FACTOR=1 which scales both the fonts and forms nicely [See attachment]. This is equivalent to adding QApplication::setAttribute(Qt::AA_EnableHighDpiScaling) where the QApplication object is constructed (where should this be in Mudlet? I've tried a number of logical points like line 137 in /src/main.cpp but after building on Win10, it didn't seem set.

Solution B: Using qt.conf or -platform windows:dpiawareness=0 is hacky and doesn't scale fonts correctly (forms are good, though).

Solution C: Set a static scaling value. (QT_SCALING_FACTOR environment variable or equivalent QApplication attribute) We absolutely wouldn't want to set a static scaling value - we want Qt to query Windows for the scaling factor and use that multiplier (looks like solution A does this).

I'm not a Qt expert, so you (Vadim) or someone else can point me in the right direction on where to set the AA_EnableHighDpiScaling attr (solution A), I'd be more than happy to build it, test it and submit a PR.

Thanks,

Colin

Launchpad Details: #LPC Colin Gannon - 2016-12-27 20:53:58 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Haven't forgotten about this - just busy working on the 3.0 release. Will revisit this right after.

Launchpad Details: #LPC Vadim Peretokin - 2017-03-04 13:10:03 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Colin, you can add the ::setAttribute call to https://github.com/Mudlet/Mudlet/blob/release_30/src/main.cpp#L113 - between line 112 and 113 (after the else and before the #ifdef). Let me know how you go - I haven't got a HiDPI screen to test with myself.

Launchpad Details: #LPC Vadim Peretokin - 2017-03-05 20:55:01 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Sure thing. Will test tonight or tomorrow night.

I've since migrated to a Mac as my primary dev box so I'll have to get my
environment set up again for Windows builds.

-Colin

On Mar 5, 2017 4:00 PM, "Vadim Peretokin" wrote:

Colin, you can add the ::setAttribute call to
https://github.com/Mudlet/Mudlet/blob/release_30/src/main.cpp#L113 -
between line 112 and 113 (after the else and before the #ifdef). Let me
know how you go - I haven't got a HiDPI screen to test with myself.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions

Launchpad Details: #LPC Colin Gannon - 2017-03-05 21:06:25 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Does this "fix" require at least a certain Qt 5.x version - remember the code has to compile for all versions back to Qt 5.0.2 - even if we resort to "#if defined" or "#if QT_VERSION > 0x05mmpp" preprocessor directives.

OTOH Someone with a real MacOs development platform will be a major plus for the Mudlet project - is there anyway we can drag you aboard Colin? 8-)

Launchpad Details: #LPC Stephen Lyons - 2017-03-05 21:17:05 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Awesome. Well, Mudlet compiles on macOS too, I'd you kept the monitor
should be good to go...

On Sun, 5 Mar 2017 10:15 pm Colin Gannon, wrote:

Sure thing. Will test tonight or tomorrow night.

I've since migrated to a Mac as my primary dev box so I'll have to get my
environment set up again for Windows builds.

-Colin

On Mar 5, 2017 4:00 PM, "Vadim Peretokin" wrote:

Colin, you can add the ::setAttribute call to
https://github.com/Mudlet/Mudlet/blob/release_30/src/main.cpp#L113 -
between line 112 and 113 (after the else and before the #ifdef). Let me
know how you go - I haven't got a HiDPI screen to test with myself.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally,
the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow
for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application
as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a
Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small
icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

Launchpad Details: #LPC Vadim Peretokin - 2017-03-05 22:11:24 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Travis will tell us if it's a problem :)

On Sun, 5 Mar 2017 10:25 pm Stephen Lyons, wrote:

Does this "fix" require at least a certain Qt 5.x version - remember the
code has to compile for all versions back to Qt 5.0.2 - even if we
resort to "#if defined" or "#if QT_VERSION > 0x05mmpp" preprocessor
directives.

OTOH Someone with a real MacOs development platform will be a major plus
for the Mudlet project - is there anyway we can drag you aboard Colin?
8-)

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

Launchpad Details: #LPC Vadim Peretokin - 2017-03-05 22:11:48 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Another thing I remembered is that our consoles aren't HiDPI aware. On macOS no option is needed to make Qt scale properly, but you'll see that the main console is not crisp:

http://cl.ly/image/3a3B3t0Y3O1t
screen shot 2014-11-28 at 00 45 15

http://cl.ly/image/320v3M2J1H2h
screen shot 2014-11-28 at 00 50 43

So the above solution will only get us halfway there I think.

Launchpad Details: #LPC Vadim Peretokin - 2017-03-06 07:03:11 +0000

Edited: 2018/01/25 by SlySven to include images directly

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

"While an effort to convert Mudlet's QML to relative values would be the "right" fix..."

Um, Mudlet is a QWidget rather than a QML application - does that mean that the given fix option is not applicable‽

Launchpad Details: #LPC Stephen Lyons - 2017-03-06 11:26:41 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Why wouldn't it? Colin has already demonstrated in a screenshot: https://bugs.launchpad.net/mudlet/+bug/1652413/+attachment/4797276/+files/wenvvar.PNG
wenvvar

Launchpad Details: #LPC Vadim Peretokin - 2017-03-06 11:37:30 +0000
Edited: 2018/01/25 by SlySven to include images directly

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

@colin: any update on this?

On Mon, Mar 6, 2017 at 12:51 PM Vadim Peretokin
wrote:

Why wouldn't it? Colin has already demonstrated in a screenshot:

https://bugs.launchpad.net/mudlet/+bug/1652413/+attachment/4797276/+files/wenvvar.PNG

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

Launchpad Details: #LPC Vadim Peretokin - 2017-03-12 05:42:20 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

I should have some time tomorrow as there's some nasty weather headed my
way. :) Sorry for the delay, in any case - work has been a little wild.

Are you looking to get this in for the 3.0 release? Also, in response to
comments regarding HiDPI on MacOS - Apple is actually sane in how they
reason about scaling and as result MacOS doesn't use the awful logic that
MSFT does so this issue is specific to HiDPI displays (> FHD) on Windows
only.

Not to split this thread/conflate issues, but what's the specific need for
a MacOS dev/platform? Builds? If so, I may be able to accommodate that if
we set up post-commit webhooks for the Github repo to do CI on an iMac I
have (it's currently mostly idle). Otherwise I'm happy to contribute on
issues/enhancements specific to the platforms I use - granted, I'm
primarily a Python developer and application security guy but I can take a
whack at some C++/qt. :)

Thanks,

Colin

On Mar 12, 2017 12:50 AM, "Vadim Peretokin" wrote:

@colin: any update on this?

On Mon, Mar 6, 2017 at 12:51 PM Vadim Peretokin
wrote:

Why wouldn't it? Colin has already demonstrated in a screenshot:

https://bugs.launchpad.net/mudlet/+bug/1652413/+
attachment/4797276/+files/wenvvar.PNG

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally,
the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow
for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application
as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a
Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small
icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions

Launchpad Details: #LPC Colin Gannon - 2017-03-13 12:39:30 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Nah don't have to rush for 3.0, that one is canned for any new features.
While we do have macOS CI setup with Travis (
https://travis-ci.org/Mudlet/Mudlet), any sort of macOS-specific
development requires me opening up my 800x600 hackintosh vm and slowly
pecking away at the keys, so any fixes/improvements for that platform would
be welcome. A lot of Mudlet's UI looks out of place on a mac for example -
fields too small and things like that - whereas it looks quite fine on a
windows/linux setup.

Let me know how you go with the HiDPI option and if'd like immediate help,
hop over to https://gitter.im/Mudlet/Mudlet!

On Mon, Mar 13, 2017 at 1:51 PM Colin Gannon wrote:

I should have some time tomorrow as there's some nasty weather headed my
way. :) Sorry for the delay, in any case - work has been a little wild.

Are you looking to get this in for the 3.0 release? Also, in response to
comments regarding HiDPI on MacOS - Apple is actually sane in how they
reason about scaling and as result MacOS doesn't use the awful logic that
MSFT does so this issue is specific to HiDPI displays (> FHD) on Windows
only.

Not to split this thread/conflate issues, but what's the specific need for
a MacOS dev/platform? Builds? If so, I may be able to accommodate that if
we set up post-commit webhooks for the Github repo to do CI on an iMac I
have (it's currently mostly idle). Otherwise I'm happy to contribute on
issues/enhancements specific to the platforms I use - granted, I'm
primarily a Python developer and application security guy but I can take a
whack at some C++/qt. :)

Thanks,

Colin

On Mar 12, 2017 12:50 AM, "Vadim Peretokin"
wrote:

@colin: any update on this?

On Mon, Mar 6, 2017 at 12:51 PM Vadim Peretokin
wrote:

Why wouldn't it? Colin has already demonstrated in a screenshot:

https://bugs.launchpad.net/mudlet/+bug/1652413/+
attachment/4797276/+files/wenvvar.PNG

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in
pixels)
in the Qt GUI widgets rather than using relative values. Additionally,
the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be
the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow
for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of

the

following (passed at runtime, instructs Windows to treat the
application
as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds

to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a
Microsoft
Surface or 4K display with scaling enabled and set to a value other
than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small
icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally,
the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow
for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application
as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a
Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small
icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions

--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1652413

Title:
DPI Awareness/Scaling Issues (Win10)

Status in Mudlet:
New

Bug description:
Summary:
Mudlet exhibits behavior associated with static size values (in pixels)
in the Qt GUI widgets rather than using relative values. Additionally, the
application does not specify DPI awareness such that Qt autoscales the
application using the native Windows display APIs.* As such, the UI is,
while usable, not properly rendered which breaks third-party UI add-ons
produced by the community.

*More info here: http://doc.qt.io/qt-5/highdpi.html

Recommended remediation (up for discussion!):
While an effort to convert Mudlet's QML to relative values would be the
"right" fix, the autoscaling provided by Qt 5.6+ and Windows 8.1+ allow for
one of the following:

 The addition of a qt.conf directive to specify an equivalent of the

following (passed at runtime, instructs Windows to treat the application as
non-DPI aware and to scale it automatically):
-platform windows:dpiawareness=0

OR

 The addition of the following property setter for Windows builds to

achieve the same goal as option #1:
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Steps to reproduce:
Run the application on a High DPI Windows 10 machine such as a Microsoft
Surface or 4K display with scaling enabled and set to a value other than
100%. Observe the UI scaling issues in the splash frame and Connections
frame - particularly cut off text and oddly shaped fields/tiny small icons.

I have tested the -platform windows:dpiawareness=0 solution and it's
working with Mudlet3-iota built against Qt5.6 on Windows 10 following
the wiki instructions. I am building and testing the second (probably
preferable) fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1652413/+subscriptions


Mailing list: https://launchpad.net/~mudlet-makers
Post to :
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp

Launchpad Details: #LPC Vadim Peretokin - 2017-03-13 13:48:45 +0000

@vadi2
Copy link
Member Author

vadi2 commented Mar 31, 2017

Another thing to look out for, as reported on Mudlet forums (http://forums.mudlet.org/viewtopic.php?f=5&t=18440&p=38972#p38972) this is how the Script editor renders on a 2560 by 1440 display on Plasma 5.9.
0uqmsro

Launchpad Details: #LPC Vadim Peretokin - 2017-03-21 09:18:08 +0000
Edited: 2018/01/25 by SlySven to include images directly

@crouthamela
Copy link

I'd like to report the same scaling issues on my QHD display (3200 x 1800) on Ubuntu 16.04. Attached are two screenshots showing how small the interface is. I recently had the same issue with kdenlive, but upon updating to the version on their PPA, it solved the issue. I assume they made some changes in their Qt code to support hidpi now that Qt supports it. Hopefully Mudlet can do the same?

screenshot from 2017-04-03 23-22-48
screenshot from 2017-04-03 23-23-12

@vadi2
Copy link
Member Author

vadi2 commented Apr 4, 2017

If you could find out what changes they did, that'd be a big help - we're not yet sure on the solution.

@vadi2
Copy link
Member Author

vadi2 commented Apr 5, 2017

@crouthamela could you redo the screenshots using this version please?

You'll need to make it executable before being able to run it.

@vadi2
Copy link
Member Author

vadi2 commented Apr 5, 2017

Also, where did you install Mudlet from to get the original screenshot? The generic Linux installer, which uses a more modern version of Qt compared to PPA, renders it ok:

workspace 1_036

It's tiny but it is scaled correctly.

@crouthamela
Copy link

@vadi2 The original screenshots from me were from 3.0.0 available through the Ubuntu PPA on the Mudlet download page. The AppImage link you sent me resolves the primary scaling issue, although the text in the main area is now very blocky and blurry. Attached screenshots are using the default font, size 12. First one is with anti-aliasing on, the second with it off.

screenshot from 2017-04-05 08-51-53
screenshot from 2017-04-05 08-54-25

@vadi2
Copy link
Member Author

vadi2 commented Apr 5, 2017

Ah pff that's just the oldschool MUD effect.

Thanks for the screenshots, this information is super helpful, will look at this more. What are your Ubuntu display scaling settings at?

@crouthamela
Copy link

Haha. Display scaling is set to 2. Thanks for working on this, I've noticed a lot of Linux apps have these same UI scaling issues as they get dragged into this whole modern "retina display" thing.

@emberian
Copy link

Reporting that I have similar/same issues as @crouthamela does with most recent GNOME 3 and a 4K monitor, QT_SCALE_FACTOR=2.

@vadi2
Copy link
Member Author

vadi2 commented May 16, 2017

Haven't got the bandwidth to be investigating it right now, it's especially difficult as I'm lacking a 4K display as well. I hope someone with one will be able to help out the project.

@vadi2
Copy link
Member Author

vadi2 commented May 16, 2017

@crouthamela @cmr what if you use QT_AUTO_SCREEN_SCALE_FACTOR=1 - do you still get the blurry main display?

@emberian
Copy link

emberian commented May 17, 2017

@vadi2 I do, yes. I hope to be able to have some time to try and debug this over the weekend.

@vadi2
Copy link
Member Author

vadi2 commented Jun 9, 2017

3.1 seems to run fine on Windows HiDPI: https://us.v-cdn.net/5020142/uploads/editor/ca/a6shyqg32s6z.png

@vadi2
Copy link
Member Author

vadi2 commented Jun 20, 2017

Another tip, put everything into layouts: https://forum.qt.io/topic/80445/dpi-problems/7

@jason-watkins
Copy link

Is there a general update on the progress of this issue somewhere? I'm a new user on a Surface Pro 4, and while the basic UI works pretty well, there are still some annoying issues in the various editor windows.

Examples:

@vadi2
Copy link
Member Author

vadi2 commented Aug 7, 2017

Try 3.4 released just today - the first screenshot might be fixed. I'm not sure about the second one!

@SlySven
Copy link
Member

SlySven commented Aug 7, 2017

Yeah I recognise that I have been hacking around in those areas recently (so that the different Mudlet item "Types" all use "Name:" (rather than "name:" or "Alias name:") and "Command:" (rather than "Substitution:" or ""send plain text:" in the samples you how tried) - so I can tell you are not using the most recently put together stuff. OTOH If I have fixed the issue it will be serendipity rather than by design...

@Ansrare
Copy link
Contributor

Ansrare commented Jan 24, 2018

I think the default is DPI unaware, so that Windows 10 is already treating Mudlet as non-DPI aware and auto scaling it, which is why it looks okay, but not awesome.
Ref: https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx(d=robot)

@Ansrare
Copy link
Contributor

Ansrare commented Jan 24, 2018

.... and I just read the Qt documentation, and I'm wrong. It's Per-system/Per-monitor DPI aware.

@vadi2 vadi2 added this to the 3.17.0 milestone Feb 2, 2019
mehulmathur16 pushed a commit to mehulmathur16/Mudlet that referenced this issue Feb 16, 2024
Breakpad now uses features from C++17: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3954471

We should make this explicit via the `breakpad_client` target requirements. This change only creates a lower bound because, for compilers that support only parts of C++17, the build will not necessarily complain. For instance, `breakpad` uses `static_assert()` without a second message parameter, which was added with https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf, which not all compilers will support that accept the C++17 standard (e.g., GCC only supports it starting from version 6).

The issue was initially raised here: getsentry/sentry-native#798 (reply in thread)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants