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

Hi,

From a wider point of view, this sounds like the right way to go. Applications with standard controls scale up beautifully in general without any additional effort, and that is important.

However, from my narrow point of view, I additionally need to be sure that I can still have the low level access to "pixel for pixel" graphics. The important questions are:

1. What mechanisms are used for determining the current (per monitor) DPI (or scaling percentage) and how is this information exposed through upp?
2. How do I create a Ctrl that works at the native "pixel-for-pixel" resolution regardless the current DPI?

As I understand it, this automatic scaling is an attempt to remove the concept of pixel as a measure of distance and replace it with a roughly one quarter of a millimeter unit (more precisely one pixel at 96 dpi).

I bet I will use Painter extensively to render correctly scaled graphics within my controls with graphical content. The Painter rendered content will obviously need to be rendered at 1:1 pixel ratio on screen.

Yes, I know: When we talk about Windows, we should avoid physical units -- meters or inches. And when we ask Windows for display DPI, we in fact ask for display scaling percentage. The result 96 "DPI" represents 100 % GUI scaling.

Instead of having just a hidpi flag, how about having a display zoom percentage instead, i.e. 100% for default DPI level and 125, 150, 200 for greater zoom levels, based on what DPI Windows reports. This would allow better control of GUI scaling whenever it is possible, like it is when text is rendered. (And we could drop the term DPI while it is misleading with its false reference to real inches.)

AND: What exactly should be used as the size reference for GUI scaling anyway? Is it the StdFontSize derived from Windows or is it the above zoom percentage derived from monitor DPI, or some strange combination thereof?

Any which way it is, I would prefer having the framework supporting any scaling levels with fine granularity. While icons may cleanly only be scaled to 1x, 2x, 3x, etc., many other aspects of GUI can benefit from greater granularity.

When I wrote: "Any which way it is, I would prefer having the framework supporting any scaling levels with fine granularity. While icons may cleanly only be scaled to 1x, 2x, 3x, etc., many other aspects of GUI can benefit from greater granularity.", I meant: "Hidpi aware" Ctrls should have access to the current "display zoom percentage" value in order to be able to scale their contents equally cleanly for any display zoom percentage (100/125/150/200%). Scaling to just 1x, 2x, 3x... is not enough.

Hi,

OK, it sounds like you have it all figured out already. Please let me hear of any progress on the subject.

Thanks,

Tom

- The code editor font is very small. I think it should be scaled accordingly regardless of the actual point size in user configurable settings. The same is true for the help content.

Hi,

Thanks! The directory selector works as expected now.

Additionally, up-scaled icons surely look sharper too.

I wonder if it would be possible to use 256x256 icons for all purposes now?

I tried to set icon for my TopWindow (using Icon()), but the downscaling does not work as expected. It feels like there is no antialias filtering present before down sampling. If the downscaling algorithm is under U++ control, could it be changed to use some antialias/low-pass filtering algorithm to give better results?

One slightly unrelated question: Why has the flag parameter FD_ZERO for FormatDoubleFix() changed to FD_ZEROS some time since the last release?