Hi,

It seems Hi-DPI aware applications now have new requirements for per monitor DPI awareness. This is new in Windows 8.1. I think we need support for this inside upp:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd4 64659%28v=vs.85%29.aspx

Best regards,

Tom

Hi,

Not having GetDPIForMonitor() does not seem to be a catastropy. I tried a few things on Windows 8.1 with two displays (UHD as primary and FullHD as secondary):

It seems we can always query "Windows main display's" DPI using GetDeviceCaps(handle,LOGPIXELSX) and GetDeviceCaps(handle,LOGPIXELSY).

If the window is moved to another display, a WM_DPICHANGED message is received with wParam LOWORD and HIWORD reporting the new DPI values of the monitor, the window was moved to.

If the initial display DPI is read at window creation time with GetDeviceCaps() and always updated when a WM_DPICHANGED message is received, I think we have it all covered.

Hi,

Thanks! Your icon scalings and other changes work well across the displays. (Of course, icons are not as sharp on UHD as one might wish, but this is a minor issue.) Drop lists and some other items still have rather small arrow heads compared to the button size. Also, the check marks in front of menu items are perhaps slightly small. On secondary display there is an overall fuzzyness issue, but more on that can be found below.

- Then the actual StdFontSize would be calculated based on the above and the TopWindow hosting display reported DPI from received WM_DPICHANGED messages

Hi,

This is what I tried.

Added file manifest.xml to the ide package to enable per-monitor DPI awareness:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
	<asmv3:application>
		<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
			<dpiAware>True/PM</dpiAware>
		</asmv3:windowsSettings>
	</asmv3:application>
</assembly>

This also needs a Custom build step to be added for WIN32 - post-link to be effective:

mt.exe -manifest manifest.xml -outputresource:$(EXEPATH);1

Then added two Size variables to TopWindow class in TopWindow.h:

	Size		currentdpi;
	Size		primarydpi;

Finally added two new cases to TopWindow::WindowProc in TopWin32.cpp:

	case WM_CREATE:{
		HDC hdc=GetDC(hwnd);
		primarydpi=Size(GetDeviceCaps(hdc,LOGPIXELSX),GetDeviceCaps(hdc,LOGPIXELSY)); // Returns primary display DPI
		ReleaseDC(hwnd,hdc);
		// RLOG(Format("WM_CREATE: primary DPI(%d,%d)",primarydpi.cx,primarydpi.cy));
		break;
	}
	case 0x02E0: // WM_DPICHANGED -- e.g. moved window to another monitor with different DPI
		// WndSetPos(Rect(*(RECT*)lParam)); // LPARAM: RECT* of suggested new window pos -- non-optimal
		
		currentdpi=Size(LOWORD(wParam),HIWORD(wParam)); // Get DPI setting for current display monitor
		// RLOG(Format("WM_DPICHANGED: current DPI(%d,%d)",currentdpi.cx,currentdpi.cy));
		if(primarydpi.cy&&currentdpi.cy){
			String face;
			int height;
			GetStdFontSys(face,height);
			SetStdFont(GetStdFont().Height(height*currentdpi.cy/primarydpi.cy));
			GUI_HiDPI_Write(currentdpi.cx>150?1:0); // This does not work optimally here. 
		}
		break;
	

Possible DPI values returned by Windows depending on scaling set in Control Panel / Display:

96 DPI = 100% scaling
120 DPI = 125% scaling
144 DPI = 150% scaling
192 DPI = 200% scaling

... but there may be even more available. I think I saw 250% somewhere already.(?)

---

The result is that Font size scales properly when moving the window between the two monitors with different DPI -- 192 and 96 in my case.

There are problems though:

- Line spacing in lists does not adjust according to the StdFontSize while the actual fonts in the lists do.
- Check boxes, radio buttons, scroll bars and spin control arrows in dialogs remain in the HI-DPI mode regardless the change in the mode.
- Manually set font sizes in TheIDE do not scale according to the changes in StdFontSize. In fact, it would be very useful to just declare a scaling percentage e.g. 25... 400 in comparison to the StdFontSize for these fonts instead of their actual sizes. This would keep them proportionally sized even in single monitor scenarios where display scaling is changed in Windows Control Panel.

Further on I think all controls should be scaled and drawn based directly on a per TopWindow defined StdFontSize. This becomes evident when opening a new dialog on a different monitor or moving it onto another monitor. Then scaling really gets out of control.

Best regards,

Tom