DPI Awareness

Windows has a setting that many users are oblivious to, but which is intended to make the screen more readable on high resolution small physical size devices. In different places it is called various things: “large fonts” or “high DPI” (dots per inch). The actual setting is determinable by:

        iHDC = getdc (0)
        ixdpi = GetDeviceCaps(iHDC, LOGPIXELSX)
        iydpi = GetDeviceCaps(iHDC, LOGPIXELSY)

and the value is referred to as “logical DPI”. A standard screen, like the one I use on a desktop PC appears to be set to a figure of 96 DPI. In all versions of Windows one can alter this setting. After a bit of experience, I have concluded that 96 DPI is present in around 95+% of cases, the 120 DPI setting is next commonest, although it is found infrequently and normally only on fancy desktop-substitute laptops. The other settings – especially the custom settings – are even rarer. My guess is that 120 DPI (125% of 96) is the first offering, and where 96 won’t do, 120 is good enough, so that most users don’t get any further. The User Experience Guidelines suggest testing programs at 120 AND 144 as well as the standard settings.

On the whole, Clearwin seems to work (by design?) regardless of the screen resolution and the DPI settings on the target computer. This appears to be because everything in a Clearwin format window is set out according to character cells (which one can see using %gd) based on the average width of a lower case character counting the whole alphabet. With DPI settings other than 96, this sometimes leads to things not lining up vertically, but that is about as bad as it gets. A simple problem of borders not appearing for %rf boxes is also related to the font scaling. As the system font has different metrics in XP and 7, ergo why the layout of some dialogs changes between the windows versions.

Where it is important, however, is there one has fixed-size bitmaps interspersed with text, so that as the character size changes, a variety of problems arise: these range from simple non-alignment, through aesthetic issues of the bitmap looking too small, right up to scrambled windows. Under XP, I have made my programs deal with this issue by finding the dpi setting, and if possible, loading the appropriately-sized bitmap from my RESOURCES, and refusing to run if the dpi setting is one I can’t cope with (usually custom settings). Bitmaps include icons and toolbar buttons, as well as GIF, JPEG and BMP images that one may use in format windows.

I regarded this as bad enough, but in Windows 7, something has changed. The DPI setting is returned as in XP, until one reaches the magic value of 144 (or more), at which point the setting returned by GetDeviceCaps goes back to 96, and the screen is scaled by the appropriate percentage automatically by Windows. The Windows 7 setting is causing me a problem. Vista apparently does something similar.

The solution to this is apparently to declare that the program is “DPI aware”. There are two ways of declaring this, the first of which is to call system subroutine and a second is to make an entry in the application manifest. Manifests are something of a mystery to me, and I suspect for most programmers. The system subroutine is a LOGICAL*4 function called SetProcess DPIAware. If you are compiling under XP, then attempting to invoke this subroutine will fail as it is not present in the user32.dll. However, if you compile under Vista/7 and link although the routine is found and incorporated, and running this programme under XP will cause a variety of mischief, so I have found that you must use GET_OS_VER@ and not call SetProcessDPIAware unless the major version number is 6 or more.

At least this goes back to being not particularly more complicated than it was under XP – although that, to my mind, was over elaborate.

Eddie

Hi Eddie (and all!) -

I have a problem which seems to be related. A program developed on a laptop with 'normal' sort of resolution, 1366 x 768. It uses various Clearwin+ windows and a Clearwin transcript window (for Fortran write statements) and looks fine. It fills most of the screen width. I am trying to transfer this program to a new computer with 3840 x 2160 resolution, but although the windows look OK, they are in a tiny area in the top left of the screen. Both computers re running Windows 10.

I added a call to SetDpiAwareness@ but this seems to do nothing at all. I have tried changing the font size, but this has different effects for different controls and of course any displayed bitmaps are entirely unaffected, with the result that window layour is messed up. The window header font sizes seem to be automatically scaled by Windows10 itself, so I lose some of the header text as well (overwritten by the minimise/restore/close icons).

What am I not seeing? Surely there should be some way to re-size everything in the whole program automatically - including the bitmaps ?

Steve,

I'll have to think about it, but it is always worth finding out and reporting what the dpi setting is. Then look at any Clearwin+ control that uses fixed pixel sizes, and adjust them depending on what dpi the screen is working at.

Eddie

Please note that the way that ClearWin+ operates is described under item 369 in cwplus.enh.

Thanks Eddie and Paul. I have made sure the DPI awareness call is the first in the program. I still get only a tiny window in top left corner of the screen. I can reduce the screen resolution (for example to 1920 x 1080) by using the Windows display settings, and that makes the program's windows and text bigger, but this rather defeats the object of having a hi-res screen! Problem is that using the screen's full resolution, although the text is all displayed OK (not clipped or blurry), it's so tiny as to be almost unreadable.

Steve,

First off, write a little program that reports the screen size and dpi settings in use through DetDeviceCaps. Then sort through your application to see what you have set to a fixed size, including font sizes. It may be a simple matter then to choose larger values if your screen is big enough and a high dpi setting is in use. My original post still applies, but it is rare enough to encounter the problem.

Eddie

Thanks Eddie -- on my original computer I have the standard 96 dpi. On the new computer, at full 3840x2160 resolution, it's 240 dpi, and when reset to 1920x1080 it's 120 dpi. I can live with 120 dpi without changing the program. The text is big enough to be legible.

However, already tried increasing the font sizes for use with 240 dpi and whatever I do it comes out messy. Problem is that it's a fairly complex program. Some windows have layouts with multiple controls (including bitmaps), some of which seem to re-scale unpredictably when I change the font size.

It would save a lot of effort if there were some overriding method to allow a program to operate at 96 or 120 dpi on a 240 dpi screen !

Steve,

It's all down to Windows scaling some elements of the Window and not others.

Clearwin+ lays things out according to a grid of average-character-size cells. You can see what they are if you introduce a %gd control. There are various ways of discovering what the character cell size in pixels is.

Also, sometimes the Windows interrogation routines lie. They return values that are already scaled. You have to experiment to find which, and as this varies between Windows versions, you also need to work out what version you are running on!

You also need bitmaps of different sizes to use with the different dpi settings.

Eddie

Thanks, Eddie.

That's what I thought. Windows itself is badly designed (well it grew, it wasn't designed!). I think for now I'll stick with the 120dpi version as it looks OK, and works fine. Am in the middle of the project now, so I shouldn't be messing with code that works otherwise (if it ain't broke.... and all that). We have data from the first live tests of the robot, and expecting many gigabytes more data over the next 6 months. It isn't going to be a simple matter to adapt this for the high-res screen, so best wait until after the project pressure has eased a bit. Happy days! I'm now 72 and should have retired years ago, but glad I have something interesting to do.

Thanks John - just what I needed today! Sometimes I get the feeling that the software I'm struggling with is even deadlier than Vogon poetry.

I'm not much of a wizz with matrix handling, so finding it hard to get my head around rotation computations. Multi-beam sonar reflections recorded in the coordinate frame of the sonar unit, which need to be rotated into the coordinate system of the robot itself (because the sonar is not at the robot centre point and is angled downwards), and then need to be rotated into absolute external coordinates using data from the navigation file that records the robot's movement and attitude. Ah, yes - a robot with attitude. A mistake calling it UX-1. It's really Marvin.

www.unexmin.eu