i had filed this as a feature request for 2.3 / 1.4 games, but it's still an issue in the 2.5 betas, so i'm trying to file this again for those versions, but i'd like to discuss and clarify first where this is an issue ...
Until a few years, computer screens always had a ratio of physical dimensions and pixel dimensions that resulted in pixel densities of around 90-120 pixels per inch (let's say 100 pixels for simplicity). So if there was an element of 100x100 pixels on screen, it was (about) 1x1 inch in size. Programs and programmers relied on that, declaring sizes in pixels, not caring about real physical size (as it was always okay).
With mobile devices and their small screens, but same pixel dimensions, pixel density rose - some had around 200ppi, others around 300ppi, etc. so an element of 100x100 pixels is way smaller on those screens. So on mobile devices, dimensioning early on became relative to the physical screen size, not relying on pixel dimensions anymore. Fonts, images, etc. stayed the desired physical size, and the additional pixels available were used to render them sharper.
This finally arrived on notebooks and desktop computers as well the last years ... apple was defacto first with a usable variant of this (working for exactly their systems only though), microsoft was doing it "right" in the long run, which resulted in "wrong" for quite a while.
But at least with windows 10 creators update things are good now for almost all use cases.
One can set a scaling factor in the systems screen resolution settings (like "try to display everything 200% of the size usually calculated, and make things sharper instead of smaller" – this can be a setting between 100 and 500%, but values between 150 and 300 are the most common).
Then, there are basically 3 modes that can be set per program:
a) default and the best: let the program handle the high density (It has to know about the scaling factor set, and render sharper instead of smaller according to this).
b) let windows 10 do the best (the program does not know about scaling but id programmed well – windows does render everything sharper that can be done, like type, and scaling everything that can't, like images). this works well for most modern windows programs.
c) let windows 10 force a scaling up in a brutal way: make the program pixels double/triple size ... this makes the programs blurry / low resolution, but they work. this is for the old programs around – if this would not be done by force, the programs would render each of their pixel to one physical pixel, making it appear way too small.
So i'm currently testing the 2.5 betas on my windows 10 fall creators update system, that has a physical screen resolution of 3840x2160 Pixels (that is twice the standard 1920x1080 in each direction), a 15,6" size, resulting in a density of almost 300ppi. My system scaling factor is set to 200%, instructing aware programs to display the same size as on a standard 1920 screen, but sharper.
The Betas are somewhat, but not completely?, aware of this in default mode a):
They render the text sharp, the scale the mouse cursor right (well, at least in software cursor mode), etc. – so they "know". but there is one big issue: the UI scaling is not respecting the systems scaling factor. So if i disable the UI scaling option within in the program, it's displayed extremely small (assuming it's running on a 3840-screen without any scaling at all). If i activate the UI scaling option, then the UI is scaled to fit in ... this is okay and as intended by the programmers, but for my taste this is way too big now – my preference would be no UI scaling and appearing as if it was running on a 1920x1080 screen.
If i change the settings in the windows compatibilty tab of the programs to option b), things get "better".
Text etc. renders sharp as intended, and the UI scaling seems to "assume" it's running on a 1920x1080 screen, therefore doing what i'd want it to do – look big enough to use, but not as enormeous as in scaled mode. So everything is fine there ... except it's windows doing the job instead of the program – windows is telling the program it's running on a 1920 screen, and it's doing the sharper rendering for the program.
While this is okay, it's not said it's very future proof ... microsoft usually is keeping such features for very long, but it's always a complication compared to a clean solution.
just to test, i switched to option c) ...
the whole program then is defactor running as a 1920x1080 version – this works perfectly, but fonts are not sharp anymore. it's okay as a last resort, but contradicting the use of a highDPI screen.
So ... what should be done?
– first, make the 2.5 versions read the system scaling factor (if they don't already?).
– then, when the UI scaling option is disabled, don't just blindly set 1 program pixel to 1 display hardware pixel as currently, but respect the set system scaling factor. So if that is set to 200%, double the displayed size of the "non-scaled" UI, if the factor is set to 250%, scale it to that, etc.
i think it's not that much of a problem to make that work actually ... read the value, and handle the UI-scaling not as binary as currently (scale to max or scale not at all).
I'm having the same "issue" on my Pixel C android tablet – that has a pixel density of around 300ppi too. Disabling the UI scaling there results in tiny tiny UI elements as well, so the app is not reading the ppi value of the device either. As this is a touch device, i'm okay though with scaling the UI anyway to make it more touchable, so it's less of an issue there.
I know Apple is handing that topic diametrally to microsoft – it might be that this is no problem on their platforms. But but i still wonder what happens on iOS or MacOS if the UI scaling is disabled – does the UI stay "usable" or is it extremely tiny as well? As i don't have the games on that platforms, i can't test it.
As this topic is a bit difficult to describe, i'd like to discuss first to make a good bug ticket, so this can be done right ... it would serve the future proofness of the IE games a whole lot if they could handle pixel density right and natively.