Handling Windows display scaling

Post Reply
SoulSpirit
Posts: 17
Joined: Wed Aug 22, 2018 1:16 pm

Handling Windows display scaling

Post by SoulSpirit »

Hi,
the UI I'm designing with Mudlet is composed of many elements which sizes are pixel-perfect.
In many cases I draw labels with a width/height (defined in pixels) that can perfectly fit text of a specific size (defined in points).

Everything goes well if Windows is set to 100% scale (control panel -> display -> scale and layout).
Image

When scale value is set to something different than 100%, my labels continue to have the size in pixels I've defined, but the text is rendered with a scale proportional to that set on Windows, and the text won't fit its Label.
Image

I don't want the UI to follow Windows scale, I want it to be pixel-perfect.
Is it possible to create a Label with text size defined in pixels? If not, is it possible to know the Windows scale, so to manually calculate text size based on the scale value?

Thanks.

xabre
Posts: 45
Joined: Thu Mar 08, 2012 7:19 pm

Re: Handling Windows display scaling

Post by xabre »

you have: setFontSize(16). Which means 16px. Which is why your label uses 16px font in both cases.

If you don't want Mudlet's gui to scale at all, Mudlet is built using Qt tolkit, so disabling (or tweaking) scaling in Qt will directly affect Mudlet.

More info here: https://www.qt.io/blog/2016/01/26/high- ... -in-qt-5-6

Would provide you some command to try out, but m not using Windows, so can't test myself.

SoulSpirit
Posts: 17
Joined: Wed Aug 22, 2018 1:16 pm

Re: Handling Windows display scaling

Post by SoulSpirit »

xabre wrote:
Wed Dec 18, 2019 2:57 pm
you have: setFontSize(16). Which means 16px. Which is why your label uses 16px font in both cases.

If you don't want Mudlet's gui to scale at all, Mudlet is built using Qt tolkit, so disabling (or tweaking) scaling in Qt will directly affect Mudlet.

More info here: https://www.qt.io/blog/2016/01/26/high- ... -in-qt-5-6

Would provide you some command to try out, but m not using Windows, so can't test myself.
That's a good starting point, but I don't want to change the way Mudlet UI is rendered, I want to change the way the UI for my MUD is rendered.

I found this old issue on github:
https://github.com/Mudlet/Mudlet/issues/800
But again, it relates to drawing the Mudlet UI, not to provide APIs for Mudlet users to handle the DPI.

According to the article you linked, there's a set of attributes in QT for reading/setting scale-related properties, but how do I access them from within a lua script executed by Mudlet?

Thanks

xabre
Posts: 45
Joined: Thu Mar 08, 2012 7:19 pm

Re: Handling Windows display scaling

Post by xabre »

So, you're saying "I don't want to change the way Mudlet UI is rendered, I just want to change the way that Mudlet UI is rendered"?

Have to distinguish few things here:

1. Client, its window and elements, which would be Mudlet. It supports scaling by using runtime switches, as documented on the link I provided.
On Linux, since I use Linux, disabling automatic scaling for Mulet it's as simple as executing: QT_AUTO_SCREEN_SCALE_FACTOR=0 mudlet
On Windows it's essentialy the same, just have to adjust paths to Mudlet's executable, either via command prompt or in shortcut file.
If you want to ajust it for each inividual mud game you play individually, well, just run each idividual game in different Mudlet window.

2. Custom game UIs, which are written using Lua, and are created and maintained by users (not Mudlet's developers), and thus cannot be automatically adjusted for users. You wrote it, it's assumed that you know what you're doing.
Mudlet's developers can help by providing better tools for creation of your custom UI, such as Geyser, but in the end you use those tools to your likings, not Mudlet's devs.

3, The game itself, data that is retrieved from the game server via a set of standard communication and data transfer protocols. Developers of the game decide what, how and in which format will be delivered to the client.

Out of those 3, client developers can only provide tools and solutions for the client, as that is the part they code and work on. And in case here, that is exactly what they provide.

xabre
Posts: 45
Joined: Thu Mar 08, 2012 7:19 pm

Re: Handling Windows display scaling

Post by xabre »

Let me try to explain to you a bit further.
You set the scaling for GUI elements to 120% in Windows, but in your script you set exctly the same font size for both cases (with and without scaling).
The dimensions of your gui element are 60x32px in both cases (with or without scaling)
Isn't it logical that same, unchanged font size won't work the same in scaled window? Or that 60x32px rectangle won't be suitable when scaled?
But that is exactly how you told it to work.

If you need adjustments according to current scaling factor, you need to create a script that calculates apropriate dimension values in your scipts.
Or simply create a global variable, something like scale_factor then call it in scripts.
Like, if your scailing factor is 1.2 (or 120%), your needed width isn't 100 but 120 (width = width* scale_factor).

SoulSpirit
Posts: 17
Joined: Wed Aug 22, 2018 1:16 pm

Re: Handling Windows display scaling

Post by SoulSpirit »

You're perfectly right, and I undestand what's happening.
I'd like to react to the scaling factor, but how do I detect it from within a Mudlet Lua script?

Thanks again.

xabre
Posts: 45
Joined: Thu Mar 08, 2012 7:19 pm

Re: Handling Windows display scaling

Post by xabre »

That would be the tricky part, as I'm not sure how Qt settings reading works on Windows.(On Linux it's as simple as reading the QT_SCREEN_SCALE_FACTORS variable via os.execute function in Mudlet, but as said, am not able to test and poke what works on Windows)

I assume (and this is just a thought while I'm still digesting all the food from yesterday, which will result in an epic crap one way or another) that you can use getMainWindowSize() to read dimensions of a Mudlet main window - in case it's mximized functions output will be almost identical to actual display resolution. Then, if output says "oo, window is 2560 pixels wide, this must be one big ass screen, or I think maybe some scaling is needed?", you can later set scale_factor based on the resolution. Nothing better comes to mind atm.

User avatar
demonnic
Posts: 884
Joined: Sat Dec 05, 2009 3:19 pm

Re: Handling Windows display scaling

Post by demonnic »

sadly, it does not look like this environment variable is available via os.execute or io.popen, both of which open a new cmd window. output of 'set' command being run doesn't have that variable name in it.

xabre
Posts: 45
Joined: Thu Mar 08, 2012 7:19 pm

Re: Handling Windows display scaling

Post by xabre »

Actually, you can go to the source of the problem, and instead of reading varibles and hoping the exist, or taking guesses based on screen resolution, I bet that PowerShell offers some kind of a way to read pixel density of the screen (dots/pixels per inch) which would give you far more representative clues on what kind of a scaling factor is the monitor built to work with.
On Linux, in case anyone cares - xdpyinfo .

Quick Googing:
https://community.spiceworks.com/how_to ... ell-script

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Handling Windows display scaling

Post by SlySven »

I've recently set up a 4K (43") TV as a second monitor (i had to buy a more modern replacement graphics card as well but that is a different tale!) - and I have just seen that Qt 5.14 (the latest one at present) has just added QFontMetricsF::fontDpi() which might be relevant in this case - though only if we build with that (or later version) and I am not sure what we are at for Windows & Linux {macOS installable builds always use the latest - which has bitten us in other ways...!}

The Qt Document High Resolution Displays might also give some pointers. I guess if it was needed we might try and find a way to pass one or more of the four: int QPaintDevice::{logical|physical}Dpi{X|Y}() const values back for a given console - if we could work out which (pair) was wanted...

Post Reply