Compile for high DPI (Retina) displays (remove fuzziness, blurriness)

[Kilmatead]

mlipok, on 23 Feb 2015 - 9:27 PM, said:

    but on Win 8.1

    Works well even without using any special directive ( I mean #AutoIt3Wrapper_Res_HiDpi=y ) and with out any workaround.

Interesting... a quick test using Win10 on a virtual machine does not change anything (the GUI is still all wrong), so just out of interest, what happens on Win8 if you use your same script manually converted into DPI-Awareness the traditional way?  I don't have Win8 so can't test it myself - but this method is the only way I know how to do it properly for XP/Win7/Win10 - your method of reducing the font-size is not fair to users.

expandcollapse popup

#AutoIt3Wrapper_res_Compatibility=Windows7
#AutoIt3Wrapper_Res_HiDpi=y

#include <WinAPI.au3>
#include <FontConstants.au3>

#include <GuiConstantsEx.au3>
#include <AVIConstants.au3>
#include <TreeViewConstants.au3>

Func _GetDPI()
    Local $hDC = _WinAPI_GetDC(0)
    Local $DPI = _WinAPI_GetDeviceCaps($hDC, $LOGPIXELSY)
    _WinAPI_ReleaseDC(0, $hDC)

    Select
        Case $DPI = 0
            $DPI = 1
        Case $DPI < 84
            $DPI /= 105
        Case $DPI < 121
            $DPI /= 96
        Case $DPI < 145
            $DPI /= 95
        Case Else
            $DPI /= 94
    EndSelect

    Return Round($DPI, 2)
EndFunc

$DPI = _GetDPI()

; GUI
GUICreate("Sample GUI", 400 * $DPI, 400 * $DPI)
GUISetIcon(@SystemDir & "\mspaint.exe", 0)

; MENU
GUICtrlCreateMenu("Menu&One")
GUICtrlCreateMenu("Menu&Two")
GUICtrlCreateMenu("MenuTh&ree")
GUICtrlCreateMenu("Menu&Four")

; CONTEXT MENU
Local $iContextMenu = GUICtrlCreateContextMenu()
GUICtrlCreateMenuItem("Context Menu", $iContextMenu)
GUICtrlCreateMenuItem("", $iContextMenu) ; Separator
GUICtrlCreateMenuItem("&Properties", $iContextMenu)

; PIC
GUICtrlCreatePic("logo4.gif", 0, 0, 169 * $DPI, 68 * $DPI)
GUICtrlCreateLabel("Sample Pic", 75 * $DPI, 1 * $DPI, 53 * $DPI, 15 * $DPI)
GUICtrlSetBkColor(-1, $GUI_BKCOLOR_TRANSPARENT)
GUICtrlSetColor(-1, 0xFFFFFF)

; AVI
GUICtrlCreateAvi("SampleAVI.avi", 0, 180 * $DPI, 10 * $DPI, 32 * $DPI, 32 * $DPI, $ACS_AUTOPLAY)
GUICtrlCreateLabel("Sample avi", 175 * $DPI, 50 * $DPI)

; TAB
GUICtrlCreateTab(240 * $DPI, 0, 150 * $DPI, 70 * $DPI)
GUICtrlCreateTabItem("One")
GUICtrlCreateLabel("Sample Tab with tabItems", 250 * $DPI, 40 * $DPI)
GUICtrlCreateTabItem("Two")
GUICtrlCreateTabItem("Three")
GUICtrlCreateTabItem("")

; COMBO
GUICtrlCreateCombo("Sample Combo", 250 * $DPI, 80 * $DPI, 120 * $DPI, 100 * $DPI)

; PROGRESS
GUICtrlCreateProgress(60 * $DPI, 80 * $DPI, 150 * $DPI, 20 * $DPI)
GUICtrlSetData(-1, 60 * $DPI)
GUICtrlCreateLabel("Progress:", 5 * $DPI, 82 * $DPI)

; EDIT
GUICtrlCreateEdit(@CRLF & "  Sample Edit Control", 10 * $DPI, 110 * $DPI, 150 * $DPI, 70 * $DPI)

; LIST
GUICtrlCreateList("", 5 * $DPI, 190 * $DPI, 100 * $DPI, 90 * $DPI)
GUICtrlSetData(-1, "A.Sample|B.List|C.Control|D.Here", "B.List")

; ICON
GUICtrlCreateIcon("explorer.exe", 0, 175 * $DPI, 120 * $DPI)
GUICtrlCreateLabel("Icon", 180 * $DPI, 160 * $DPI, 50 * $DPI, 20 * $DPI)

; LIST VIEW
Local $iListView = GUICtrlCreateListView("Sample|ListView|", 110 * $DPI, 190 * $DPI, 110 * $DPI, 80 * $DPI)
GUICtrlCreateListViewItem("A|One", $iListView)
GUICtrlCreateListViewItem("B|Two", $iListView)
GUICtrlCreateListViewItem("C|Three", $iListView)

; GROUP WITH RADIO BUTTONS
GUICtrlCreateGroup("Sample Group", 230 * $DPI, 120 * $DPI)
GUICtrlCreateRadio("Radio One", 250 * $DPI, 140 * $DPI, 80 * $DPI)
GUICtrlSetState(-1, $GUI_CHECKED)
GUICtrlCreateRadio("Radio Two", 250 * $DPI, 165 * $DPI, 80 * $DPI)
GUICtrlCreateGroup("", -99, -99, 1, 1) ;close group

; UPDOWN
GUICtrlCreateLabel("UpDown", 350 * $DPI, 115 * $DPI)
GUICtrlCreateInput("42", 350 * $DPI, 130 * $DPI, 40 * $DPI, 20 * $DPI)
GUICtrlCreateUpdown(-1)

; LABEL
GUICtrlCreateLabel("Green" & @CRLF & "Label", 350 * $DPI, 165 * $DPI, 40 * $DPI, 40 * $DPI)
GUICtrlSetBkColor(-1, 0x00FF00)

; SLIDER
GUICtrlCreateLabel("Slider:", 235 * $DPI, 215 * $DPI)
GUICtrlCreateSlider(270 * $DPI, 210 * $DPI, 120 * $DPI, 30 * $DPI)
GUICtrlSetData(-1, 30 * $DPI)

; INPUT
GUICtrlCreateInput("Sample Input Box", 235 * $DPI, 255 * $DPI, 130 * $DPI, 20 * $DPI)

; DATE
GUICtrlCreateDate("", 5 * $DPI, 280 * $DPI, 200 * $DPI, 20 * $DPI)
GUICtrlCreateLabel("(Date control expands into a calendar)", 10 * $DPI, 305 * $DPI, 200 * $DPI, 20 * $DPI)

; BUTTON
GUICtrlCreateButton("Sample Button", 10 * $DPI, 330 * $DPI, 100 * $DPI, 30 * $DPI)

; CHECKBOX
GUICtrlCreateCheckbox("Checkbox", 130 * $DPI, 335 * $DPI, 80 * $DPI, 20 * $DPI)
GUICtrlSetState(-1, $GUI_CHECKED)

; TREEVIEW ONE
Local $iTreeView_1 = GUICtrlCreateTreeView(210 * $DPI, 290 * $DPI, 80 * $DPI, 80 * $DPI)
Local $iTreeItem = GUICtrlCreateTreeViewItem("TreeView", $iTreeView_1)
GUICtrlCreateTreeViewItem("Item1", $iTreeItem)
GUICtrlCreateTreeViewItem("Item2", $iTreeItem)
GUICtrlCreateTreeViewItem("Foo", -1)
GUICtrlSetState($iTreeItem, $GUI_EXPAND)

; TREEVIEW TWO
Local $iTreeView_2 = GUICtrlCreateTreeView(295 * $DPI, 290 * $DPI, 103 * $DPI, 80 * $DPI, $TVS_CHECKBOXES)
GUICtrlCreateTreeViewItem("TreeView", $iTreeView_2)
GUICtrlCreateTreeViewItem("With", $iTreeView_2)
GUICtrlCreateTreeViewItem("$TVS_CHECKBOXES", $iTreeView_2)
GUICtrlSetState(-1, $GUI_CHECKED)
GUICtrlCreateTreeViewItem("Style", $iTreeView_2)

; GUI MESSAGE LOOP
GUISetState(@SW_SHOW)
While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit

    EndSwitch
WEnd

And before you ask, no, the new Wrapper directive does not work for me either on Win7... I don't think there is a "simple" solution.  Since reducing the font by DPI ratio defeats the purpose of DPI the only other means is the old-fashioned way of blood sweat and tears.  And lots of multiplication.

[mLipok]

@Kilmatead
if you look in my Signature then you find Writing DPI Awareness App - workaround

So how you can see I know how to make a workaround.

btw. on Win 8.1 it looks like this workaround successufully fix the font size in the same way like on Win7.

[Kilmatead]

Yes, your thread is a work-around, but it's a cruel one to any users of your scripts - people set higher DPI precisely to avoid the uselessness of small text, so reducing text size merely to match the GUI is at best a kludge.  The alternate approach (above) is to expand the relative location and size of each control as they are created, which initially looks like a lot of work, but it's not in the long run - and you end up with a GUI that works perfectly on all machines, but most importantly respects the user's choice to work under high DPI.

 

The MS article this thread refers to does not actually seem to suggest that merely changing the manifest will result in a magic bullet - it only seems to apply against the enforced WDM DPI scaling.  It won't apply any scaling itself (as I read it).

[mLipok]

I respect.

Things are not always as simple as they seem.

I do not know whether you thought about the two possibilities:

 

Case 1.

If you expand the appropriate size of all controls and window size if at some applications may not fit on the screen.

 

 

Case 2:

If the program was by design, created for resolution 1366x768

and spacing of all controls are fully optimized, imagine that you change the resolution to 1440x900 and sets 150% DPI (because so fond of).

Can you imagine how to fit all controls in exactly the same place?

 

 

In any case, I understand that there may be such a situation:

Case 3:

The program has a small GUI or with a small amount of elements / controls.

Increase %DPI should increase the size of all the GUI elements of the program.

[Mugen]

The increase of size should not matter.

Remember, users set high dpi settings on very high resolutions (usually 1920x1080 or higher)

[Kilmatead]

 

If the program was by design, created for resolution 1366x768

and spacing of all controls are fully optimized, imagine that you change the resolution to 1440x900 and sets 150% DPI (because so fond of).

Can you imagine how to fit all controls in exactly the same place?

 

Actually, an interesting thing happens when the user sets DPI at 150 or above - the actual reported scaling ratio goes back to 1.  Up to 150 the ratio works as expected - 125% simply results in a factor of 1.25, etc.  However, at >= 150% Windows itself seems to automatically handle the upscaling and it does not report 1.5 (as we would expect), it returns 1 instead, which is harmless.

[mLipok]

Win version?

[Kilmatead]

Win7.  I should be more specific and say that that applies when the user allows Windows to determine whether the "Use XP Scaling" is active or not.  When you set DPI of 125 Windows activates that checkbox by default, though it de-activates it (automatically) at anything over 150.  If the user overrides this, then the scaling factor does indeed multiply beyond useful measure, and then things can go wrong.

As that setting is one of the causes of the "blurriness" factor people often encounter, the user is responsible for what happens if they change such settings themselves without knowing the impact.

It's not a perfect system, but it beats squinting at everything.

[Mugen]

Maybe useful, you can determine the compatible mode flags using envget.

MsgBox(0, "", EnvGet("__COMPAT_LAYER"))

[Kilmatead]

...you can determine the compatible mode flags using envget.

 

Not for this - the "Use Windows XP style DPI scaling" is not a compatibility mode, it's actually what this thread is all about.  On Win7 when you select a custom DPI (emphasis on custom) and in Win8 as well (though in a slightly different place) the options window has an extra checkbox which is what controls the system-wide DWM scaling (sometimes called "DPI Virtualisation") that was introduced in Vista+.

Basically it's what this manifest setting actually does: declaring an application DPI "aware" means that the application itself is 100% responsible for any scaling (as it was in XP).  Normally (as above) if the user selects a DPI of 150 Windows automatically enables DPI Virtualisation (i.e., it's the same as forcing the Use Windows XP style box to be unchecked).  This is what causes the blurriness that people don't like.  On the other hand, it does conveniently scale all elements of a (non-aware) GUI in a nice clean way - no worrying about either calculating the expansion of individual controls, or reducing the font size or however one cares to handle it.

At the end of the day, it's the same as the API's SetProcessDPIAware function, though AutoIt binaries have a tendency to resist that function's affections for some reason.

Above, when I found that the DPI ratio was incorrectly being reported as 1 (instead of 1.5) that's the DPI Virtualisation getting in the way - when DPI awareness is set (by whatever method), the ratio will always return 1.5, regardless of what setting the user selected.  The downside of this is that it is indeed not a magic bullet for scaling, and the developer has to do everything himself.

Another downside is that some versions of obtaining the DPI setting will fail on these compiled EXE's because for some unknown reason the GDI+ method of reading the ratio fails when Awareness is set - but there are other methods available, like the one I used above (stolen and simplified from Phillip123Adams approach, found in an old post of his which has since slipped into the aether).

Adding DPI-awareness to the wrapper is a good thing, if for no other reason than the user's programme will always behave predictably (and report the proper DPI) no matter what options in Windows were set or unset (beyond the dev's purview).  And by "predictably" I mean that it will always have an ugly/skewed GUI because DPI Virtualisation can never be applied to it, thus requiring the dev to either shrink the font size (boo hiss!) or handle the control scaling on an individual  basis himself.  That part's up to us.

All that being said, for those who don't mind letting Windows handle things, all they have to do is ignore this wrapper setting and tell their complaining users to uncheck the Use Windows XP style DPI scaling box like they've always done, and learn to live with the blur.

Final verdict (at least by me): #AutoIt3Wrapper_Res_HiDpi=Y does work, and it's good thing, but it just doesn't work the way we hoped it would.  There just is no magic bullet, and no substitute for hard work.

Edited February 25, 2015 by Kilmatead