Resolving High-DPI Scaling Issues for Windows* Apps

This is a computer translation of the original content. It is provided for general information only and should not be relied upon as complete or accurate.

This blog address DPI Scaling issues for Windows* Apps

Overview

There is currently a proliferation of many different form factors now available on the market. There are high-DPI tablets, notebooks, 2 in 1’s, All-in-Ones, etc. With variety and choice of devices, comes both high-DPI and DPI scaling issues that modern-day apps must address. Today’s app developer needs to write apps that are DPI-aware. Let's start with some definitions:

DPI: Number of dots in one linear inch. More dots means a higher quality picture. DPI, properly used refers to the resolution of a printer, however DPI is also the relation between size in pixels and the actual display size.

Resolution: the number of pixels that make up a picture whether it is printed on paper or displayed on a computer screen. Higher resolution provides the capability to display more detail.

Higher DPI = Higher resolution, however, resolution does not refer to size, it refers to the number of pixels in each dimension.

DPI Awareness: an app takes the DPI setting into account, making it possible for an application to behave as if it knew the real size of the pixels.

At 300 DPI, there are 300 pixels per inch. There are 72 points per inch. So 4.16 Pixels = 1 point

At 96 DPI and 72 points per inch, there are 1.33 pixels in one point.

To provide context of how apps deal with DPI issues (or not), here are some definitions:

Not DPI-aware applications – these applications always render at 96 DPI, the lowest desktop DPI setting. This class of application is unaware of different system DPIs. These applications rely on the Desktop Window Manager (DWM) to virtualize and scale to account for high DPI.

System-DPI aware applications – these applications are DPI-aware in Windows Vista through Windows 8. They are rendered at the system DPI in order to avoid being scaled.

Per Monitor-DPI aware applications – These are a new class of applications in Windows 8.1. They dynamically scale up or down when a user changes the DPI or moves the application between monitors that have varying DPIs. These applications render crisply and correctly regardless of the current display. The DWM does not scale and virtualize these applications.

Generally speaking for Win 32 app development, if an app is developed using Windows Presentation Foundation (WPF) and designed for Windows 8 and uses all the standard Windows Controls and elements then there shouldn't really be any issues. Problems arise when writing custom or heavily skinned windows elements and GUIs (also if using some of the other Windows Frameworks like Qt.)

The following paragraphs outline what issues app developers are experiencing and what can be done to minimize DPI Scaling issues moving forward. Note, however ,that if the app is designed with DPI scaling in mind in the first place then the issues below will most likely be minimal if not non-existent.

Potential Issues with High DPI Monitors

Content hard to see - UI targets difficult to click/tap

Increased resolution decreases the size of each pixel. By decreasing the size of each pixel, the content shown on the display appears smaller. When DPI becomes sufficiently dense, this results in a shrinking effect that can cause content to be hard to see and UI targets difficult to click/tap.

Clipped UI Elements or Text

Incorrect Font Size

Incorrect Layout

Pixelated Text

Blurred UI Elements:

Windows 8.1 has DPI auto scaling which makes some applications that are not DPI aware look fuzzy.

Input Issues:

Drag-and-drop operations no longer work during virtualization due to the misalignment of an application's coordinate space when it is remapped to the system's coordinate space during scaling.

Partial rendering of a Full-screen Application

Scaling Bit-mapped graphics:

Scaling up from a lower-dpi image, beyond a certain point causes it to become pixelated and loses quality. Scaling down from a single high-resolution master image, causes loss of detail.

Custom Gestures:

incorrectly receiving the physical pixel co-ordinates on screen rather than the virtual scaled pixel co-ordinates

Example of an application running at 2560X1440 resolution and is not DPI-Aware

For bit-mapped grapics, create multiple versions of each interface bitmat to match the preset dpi settings

If you cant create 4 versions create at least two (96 and 120 dpi as they are the most common)

DPI setting

Icon (SM_CXICON)

Small icon (SM_CXSMICON)

96

32x32

16x16

120

40x40

20x20

144

48x48

24x24

192

64x64

32x32

DPI Settings vs Minimum Resolution

To assess an application's DPI compatibility, test it at a variety of resolutions with different high DPI settings. This can be done fairly easy using Virtual Machines with the different resolution settings. The following table provides a recommended set of DPI settings and minimum resolutions to consider when testing DPI awareness level. The chosen DPI setting should be close to the physical DPI that the monitor is capable of. For example, if your display has a native resolution of 1440x900 pixels and a physical display of 14.4 inches x 9 inches, the phisical DPI is 100 DPI ( 1440 horizontal pixels/ 14.4 horizontal inches.)

Calculate your physical DPI:

Resources

The following resources were found during the compilation of this blog. The articles from Ars Technica and Anandtech are good examples that can help us understand the consequences of not designing for multiple DPI systems and how some of these apps can experience issues when run on High-DPI devices.