The Evolution of DPI Over the Years

What is DPI?

DPI (dots per inch) is a terminology originally coined for the print media to describe the resolution of the printed output – a higher DPI indicated more dots of ink per inch of the output and hence a sharper text/image.

In the initial days of computers, DPI was used to indicate the density of dots (or, in this case, virtual pixels) per inch of the screen. Technically, the term that accurately describes this metric is PPI (pixels per inch), but the use of DPI, which started with early Macintosh and Windows computers, still prevails today.

There are two kinds of PPI values that are of potential interest:

Logical PPI – T PPI that the operating system assumes is provided by the display – it can be thought of as the property of the virtual screen assumed by the OS

Physical PPI – The physical pixels per inch that a display monitor provides (corresponds to its native resolution)

A brief history of DPI processing on Windows

At the onset of the personal computer age, the problems to be solved when it came to displaying content digitally on a screen were quite unique. Early display systems had a physical PPI of 72 pixels per inch – this led to a natural choice of the 72 points per inch (‘points’ are a physical unit of measure in typography, dating from the days of printing presses, where 1 point by the modern definition is 1⁄72 of the international inch) by the Macintosh OS to mirror the physical PPI of the prevalent display systems. This meant that the 72 PPI seen on display had the same physical dimensions as the 72 DPI  later seen on a printout, with 1 dot in printed text equal to 1 pixel on the display screen. This also meant that some of the early display sizes corresponded to the current standard office paper sizes.

As a result of Apple’s design of one-to-one mapping of display units with print units, the standard 10-point font size from the typewriter-era would be rendered using 10 pixels on the physical display. This led to a couple of problems:

• It made the then standard 10-point fonts to be displayed poorly, and difficult to read, particularly the lower-case characters
• Moreover, since computer displays were typically viewed at a greater distance than print media, there was a difference in the perceived size of the same 10pt font rendered on the computer display from that on print media.

Microsoft attempted to solve both problems with what could essentially, in hindsight, be called a hack.  It wrote its display software in a way to treat the screen as having 4/3^rd of its actual PPI. Since most screens at the time provided 72 PPI, Microsoft essentially wrote its software to assume that every screen provides 96 PPI (as 72 x 4/3 = 96).

This hack resulted in the following short-term benefits:

• Since the software assumes that one-third more pixels are available for rendering, fonts were rendered with greater detail
• On displays that provided 72 PPI, every character of text would be rendered at a size one-third larger than it should be, thereby allowing a person sitting at a comfortable distance from the screen to view the rendered text clearly

On the flip side, it led to the following negative effects:

• Exaggerated sizes of the rendered elements meant less available screen estate, in a relative sense
• The 1:1 relationship between display and print was lost. This led to problems because more exaggerated as display screens of different sizes and PPIs started to emerge.

To solve these, Microsoft came up with a virtual screen mechanism wherein the software programs render the text and images onto a virtual screen, and the OS translates the virtual screen onto the physical screen. The logical PPI is associated with this virtual screen, and this allows older programs to still run properly irrespective of the actual PPI of the screen.

High-DPI displays started emerging in the post-Windows XP era and became mainstream around the Windows 8 era. Although display scaling by entering a custom DPI was allowed from Windows 95, it became an easily accessible feature from Windows 8, wherein the scaling was a percentage selection instead of custom DPI values being entered.

With the introduction of the GDI+ library, resolution-independent text scaling was made possible. Additionally, Windows Vista allowed programs to declare themselves as being DPI-aware via a manifest file or using an API. For programs that did not declare themselves to be DPI-aware, the OS had a compatibility feature called DPI virtualization – which essentially meant that programs would continue to assume 96 DPI (irrespective of the actual DPI setting), and the Desktop Window Manager would then scale the application’s window to match the actual DPI setting. This led to an effect akin to zooming on an image – thereby resulting in a reduction in the sharpness of the rendered images and text.

Windows 7 made the DPI settings even more accessible, with the ability to affect changes with only a log-off and log-in, instead of a full restart, and made it a per-user setting. Another big upgrade was the automatic setting of the default DPI setting by reading and matching the physical pixel density of the display monitor. In Windows 10, manual control over DPI scaling was introduced for individual monitors.

Making an application DPI-aware

As stated above, the default scaling of non-DPI-aware application windows resulted in less than optimum results, namely blurry or incorrectly sized windows in many common usage scenarios. To fully utilize the DPI technology of the OS, it becomes imperative to make applications DPI-aware. This would help achieve proper scaling of the window and its contents with changes in DPI settings and an overall sharper rendering of the text and other UI elements in the application window.

Applications built on the Universal Windows Platform (UWP) have dynamic scaling built-in, and no additional code is necessary to make them DPI-aware. For applications built using other technologies, such as Win32, Windows Forms, Windows Presentation Framework (WPF), etc., will require additional development to make them DPI-aware and hence scale properly with the DPI.

Several legacy Windows desktop applications incorrectly assume that the DPI setting would ideally not change during the lifetime of the application. The DPI can, in fact, change in the following scenarios:

• When switching between different monitors (with different default DPI settings)
• Moving the application between monitors in a multi-monitor setup
• Connecting/disconnecting an external monitor to a laptop
• Connecting via remote desktop from a high DPI device to a low DPI device (or vice versa)
• Making DPI changes while the application is running

If applications do not dynamically respond to these changes, it can result in blurry or incorrectly sized windows.

In order to bring in DPI awareness, the application needs to first inform the OS about its level of DPI awareness:

DPI unaware – This is the default mode which is assumed if the application doesn’t  inform the OS about its DPI awareness. In this case, the OS will simply perform bitmap stretching of the window to the expected size in cases of DPI setting being anything other than 96 (100% scale). This results in a blurry render.

System DPI awareness – Applications that declare themselves as being system DPI-aware will take the value of the DPI setting at the time of startup and then use that to come up with the dimensions and positions of the window as well as the size of UI artifacts being rendered. This will ensure bitmap scaling is not done by the OS at that DPI setting. However, the DPI setting is changed (or the monitor is switched to a different DPI one etc.), then the OS will perform bitmap scaling of the application, and the output will still appear blurred.

Per monitor DPI awareness – Declaring as per-monitor DPI-aware will allow applications to dynamically render correctly whenever the DPI changes – for whatever reason. For such applications, whenever the DPI changes, the OS will not allow bitmap to scale the window but will instead send the WM_DPICHANGED message to the application window. This will allow the application an opportunity to recalculate all its dimensions, positions, text sizes etc. essentially scaling everything to the newly changed DPI setting and redrawing the window. This is the recommended method to allow for a rich and dynamic window experience.

To make existing applications DPI-aware, the following checks need to be made:

• Mark the application as being per-monitor DPI-aware in its manifest file
• Handle the WM_DPICHANGED message. This will require re-dimensioning of the key UI artifacts and re-assigning of defaults that can impact the size and position of the UI artifacts, such as text size
• Changing any legacy Win32 APIs that do not work with any DPI context. Some of these APIs are listed below, along with their DPI aware counterparts:

Read More: 

• AI Winter or AI Spring – Where are We Headed?
• Choosing the Right Cloud Service Provider to Maximise Business Efficiency
• Advantages of 64 bit OS Over 32 bit OS