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:

On Windows XP the system fonts and some system UI elements are scaled up at runtime,
but this leads to the common problem of text appearing larger and being clipped as
the actual size of the bounding control is usually not scaled.

On Windows Vista and above a feature called "DPI-virtualization" automatically scales
windows belonging to an application not marked as "DPI-aware" - in effect they are
rendered at 96 DPI to an off-screen bitmap, resized, and then drawn to the screen,
but this can result in some blurry windows due to pixel stretching.  OpenInsight
10 is marked as a DPI-aware application so it will not be subjected to DPI-virualization.

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:

Size coordinates

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

Further reading

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

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

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

The DPI of the monitor a form is displayed on changes, or
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:

Fonts are scaled
Coordinates are scaled
DPI-aware images are selected and/or scaled

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:

Revelation Conference

The previous Revelation Software Users' Conference was held at the Omni Orlando Resort at Championsgate in Orlando, Florida on April 18-21, 2016.

Click Here

On The Road

Throughout the year Revelation Software attends various multivalue User Conferences as well as our Regional User Group meetings.

Click Here

International Offices

Revelation Software has various International Offices and sales regions located on multiple continents.

Click Here

Featured Clients

Revelation Software's clients are involved in every industry around the world. Here is a sampling of some of our clients and their businesses

Click Here