OpenInsight and High-DPI

With the increasing popularity of high-resolution monitors, one of the biggest usability problems today is the display size of text and UI controls, because they appear smaller as the screen resolution increases.  The recommended advice to overcome this is to increase the DPI (dots-per-inch) setting of the system, thereby enlarging these elements and making them easier to see and read.  If you have been using Windows Vista and above you have probably already seen this Control Panel applet that allows you to easily change your DPI settings:

 

 

However, unless an application is designed to be DPI-aware this can result in some unsatisfactory results, such as over-large fonts, clipped controls and blurry windows.  This is because many older Windows applications assume a constant DPI (96) when setting font and size coordinates and they do not apply any scaling to these values, thereby resulting in the aforementioned problems

 

In an effort to accommodate these applications Microsoft have introduced a couple of OS features over the years:

 

 

OpenInsight 10, High-DPI and automatic scaling

 

OpenInsight 10 supports High-DPI by automatically scaling-up all GUI objects at runtime when created through the SYSTEM object's CREATE method (formerly known as the "Utility CREATE service").  This affects the following two properties:

 

 

The actual scaling for coordinates is calculated by the following simple formula:

 

screenPixels = logicalPixels * ( currentDPI / 96 )

 

For example, if you create a control with a size of 200x100 and you are running at 144 DPI (i.e. 150% as per the Control Panel applet above) then the control will be created with an actual size of 300x150 pixels.

 

The font point size is similarly multiplied by the scaling factor (i.e. currentDPI / 96 ).

 

Supporting images under High-DPI

 

Another noticeable issue when running at high DPI settings are images, which are assumed to have been designed for 96 DPI and therefore have to be scaled up at runtime leading to potential loss of quality due to the resize.  To help with this the tool-set has been extended to allow repository BITMAP entities to specify multiple image files when being defined.  The first will be used for 96 DPI (100%), the second for up to 120 DPI (125%), the third for up to 144 DPI (150%), the fourth for up to 192 DPI (200%) and so on, with further images being defined at 48 DPI (50%) increments.  When a control is created at runtime the system picks the appropriate image size and scales it as needed (preferably down where possible) before applying any other transformations.  Note that this does NOT apply to images set at runtime in code via the BITMAP property.  In this case the developer is assumed to have selected the correct image file size regardless of the DPI setting.

 

Designing under High-DPI

 

Of course, we always try our best not to break existing applications so you can set an option in the RXI file to turn off the automatic DPI scaling if you wish (this option is exposed at runtime via the read-only SYSTEM DPISCALING property).

 

This same principle can also be applied to individual windows at design-time so you can use it selectively as needed (WINDOW objects also support the read-only DPISCALING property).

 

Further reading

 

If you want to find out more information on this topic please see the following link to Microsoft's documentation on MSDN:

 

Writing High-DPI win32 Applications

 

 

In the example above both forms are running on a desktop set to 144 DPI (150%).  The top form is running under OpenInsight v9 and, as you can see, has been stretched by the system resulting in blurry outlines, icons, and text.  In contrast, the bottom form is running under OpenInsight v10 and has been scaled correctly - the checkbox image and icon are sharp and the font has been scaled to correct point size.

 

However, with the release of Windows 8.1 Microsoft have made some significant changes in this area that has also led to changes in OpenInsight's High-DPI handling as well.  Until Windows 8.1 the DPI setting for the system was constant across all monitors and fixed during the login process - selecting another DPI setting required logging out and back again, or even a full reboot in the case of Windows XP.  Now, with the steady increase in monitor resolutions across different form factors, Microsoft have added the ability to set the DPI per monitor, which means that forms created on one monitor may look too small or too big when moved to another monitor with a different DPI.

 

In order to deal with this at runtime, top-level forms are now notified by a new Windows message called WM_DPICHANGED, which is sent when either of the following happens:

 

  1. The DPI of the monitor a form is displayed on changes, or

  2. The form is moved between monitors that have different DPI settings.

 

This message is used by OpenInsight to adjust the scale of a form dynamically as required, so if a form's DPISCALING property is TRUE you will see this happen as you drag it across monitors with different DPIs.  All the rules described above apply:

 

 

We have also added a new property call DPI to the WINDOW object, which returns the DPI of the monitor that the window is currently displayed on.

 

The fact that scaling has moved from a static to a dynamic operation has also led to the implementation of a new OpenInsight WINDOW property called SCALEFACTOR, which allows you to set the scale of a form to an arbitrary value at runtime, regardless of any DPI setting.

 

You can find more information on Windows 8.1 per-monitor DPI scaling here: