Feature: Automatic UI and font zoom levels. #8537
Conversation
michicc
force-pushed
the
pr/autozoom_setting
branch
from
adb76da to
39d8294
Compare
|
Stripped OSX for now, will tack it on #8519 later. |
michicc
force-pushed
the
pr/autozoom_setting
branch
2 times, most recently
from
a4dd7f8 to
bb75c00
Compare
|
Improved Win32 code a bit. |
michicc
force-pushed
the
pr/autozoom_setting
branch
2 times, most recently
from
2f3ab7a to
df7245c
Compare
michicc
force-pushed
the
pr/autozoom_setting
branch
from
df7245c to
a7199b4
Compare
There was a problem hiding this comment.
In general, I think we should do something like this.
But, there is a but: we only have this for Windows implemented now. The commit message "Feature: .." suggests it is implemented for all. On all video drivers you can see the "auto" value. Yet, on most, it doesn't really do anything.
Not sure how to deal with this. Possibly simply change the feature into making it clear it is only for a select subset of video-drivers, but .. dunno :)
TrueBrain
added
candidate: yes
|
General comment: Per previous IRC chat, apparently SDL (at least as currently used by us) has no concept of a HiDPI window, which means nothing to scale. On OSX, we currently force OS scaling, automatic zoom would only be a thing together with #8519. Specific comments will be dealt with later. |
For a moment I was thinking: maybe we shouldn't show the "auto" option for SDL, for example. But I realised ... nobody is going to care if there is an "auto" option in there, that doesn't do anything for their driver. They simply will not notice. So that is just extra work for no added benefit. So yeah, forget about all that, let's just make this a generic "feature" on which we should extend. For example, SDL does have HiDPI support just fine, but we don't use it. There is a bit of work to do for us to support it, but not much. So we might as well. There are functions like |
So I was thinking this would be simple, SDL is giving us a function, so how hard could it be? Well, for Windows, it is fine. But we of course mostly target Linux with SDL ... euh .. yeah ... Someone worked out nicely how SDL behaves here, which you can read here: And if we look in the SDL source, we found on X11 Long story short: This would be similar to how Win32 driver now solves it, so that might be okay, but do we want to go that route, I wonder? |
michicc
force-pushed
the
pr/autozoom_setting
branch
3 times, most recently
from
034c181 to
a9b2199
Compare
Use the same Windows XP target as for 64-bit. Current MSVC version will not produce a binary that works on anything earlier anyway.
The zoom level suggestion is based on the DPI scaling set in Windows. We use 150% scaling as the threshold for 2X zoom and 300% scaling as the threshold for 4X zoom.
michicc
force-pushed
the
pr/autozoom_setting
branch
from
a9b2199 to
ed4238b
Compare
Motivation / Problem
On HiDPI screens, the default GUI and font zoom might be too small to read.
Description
An additional (and default) "auto" value for the zoom settings is added, that will get the current DPI value/scaling from the video driver and choose a zoom value accordingly.
For Win32 and OSX, the set thresholds are 2X zoom at a DPI scale > 150% and 4X zoom at a scale > 300%. Current OSX version will only report 100% or 200% for the scale factor, but the implementation still checks for 300% to allow for future OSX updates.
Limitations
I've marked this as a draft, as the OSX zoom level suggestion as implemented in this PR right now only makes sense together with #8519. It is it's own commit, so it could easily be stripped off for now.
It is also missing a SDL implementation, at least if HiDPI is a thing with SDL.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.
The bug fix is important enough to be backported? (label: 'backport requested')This PR affects the save game format? (label 'savegame upgrade')This PR affects the GS/AI API? (label 'needs review: Script API')This PR affects the NewGRF API? (label 'needs review: NewGRF')