For several years now, mobile device manufacturers have been in a race to push the pixel density of mobile devices higher and higher. The race began with the iPhone 4 “Retina” display – an at the time impressive 330 pixels per inch (PPI) 960x640 3.5” display. Keen to trump the Retina moniker, makers of Android devices soon churned out devices with displays with PPIs of 440 and higher, with the current push to 2560x1440 displays in 5.5” or smaller sizes which yield an amazing 500+ PPI. Next up was a similar race in the tablet space, with 1280x800 soon giving way to 2560x1600 displays, but this time in a 7” to 10” form factor.

All the while, the lowly PC and Mac chugged along with displays that could hardly be called impressive. The standard LCD display of just a few years ago would hover somewhere around 96 PPI, and it was often lower. A 17” LCD with a resolution of 1280x1024 wasn’t an accident – it was exactly 96 PPI, which is what the PC and Mac would render at by default. High resolution laptops would barely squeak past the 120 PPI range. These lower densities – though decent for the longer view distances of desktop monitors – have until recently not been improved on, highlighting the gap in progress between the two devices categories.

Further complicating matters, desktops and mobile devices have always differed in how they use resolution when it is increased. On a mobile device, higher resolution has been used to increase image quality, while higher resolution displays on a desktop were released as part of physically larger displays and used to increase the amount of work you can do. Mobile devices have had one big advantage: they are backed by new operating systems that are built for higher resolution out of the box, and there is no back catalog of legacy applications to deal with. Phones and tablets can easily deal with high resolution displays, but for the PC and Mac, things are not so simple.

In 2012, Apple launched the 15.4” Retina MacBook Pro. At the time it was far and away the highest PPI laptop available. It took a lot of work for Apple to ensure a high resolution display was usable because for really the first time, increased resolution on a computer was used to improve image quality rather than simply to increase screen real estate. How they achieved this was nicely explained by Anand back in 2012. However, OS X wasn’t perfect; certain applications didn’t behave as well as they should have, which resulted in some applications having blurry text or other UI issues. Still, Apple was able to make the Retina display work, and for the applications that were Retina aware, the result was a fantastic experience. If developers updated their applications, their clients could enjoy the high resolution clarity that had already taken over the mobile space.

But what about Windows? Windows Vista, and then Windows 7, both had support for higher DPI (Dots Per Inch) settings; even lowly Windows XP had some support for DPI scaling. The main issue was that there was no market force pushing for High DPI (in the operating system and APIs, it’s referenced as DPI as opposed to the PPI of a display) like there was with the Retina MacBook Pro. OEMs were happy to sell consumers low cost, low resolution 1366x768 TN panels for years. If people don’t demand better, most OEMs are unlikely to provide them better than the basics in such a low margin industry.

What changed was a combination of High DPI tablets and the Retina MacBook Pro putting pressure on the PC industry to offer something better. It has taken a long time, but finally quality displays are something that are important enough to consumers for every single major OEM to now offer at least one, if not multiple, devices with High DPI.

The Old Way - Windows XP Scaling

As mentioned, Windows XP does have support for higher density displays, but the experience is rarely very good. Changing the DPI settings in Windows XP increases the font size and OS elements, making everything larger on the screen. It works up to a point, but if the system DPI setting is too high, many applications have issues. Even in XP, there’s an API that allows a developer to check what the fonts are set at and scale their forms as needed to make it work with that ratio of font. However, if an application doesn’t check the font DPI level, there are often problems: text boxes overlap UI elements, form fields have text spill out the top or bottom of the field, and other nasty ugliness.

Even the OS doesn’t scale very nicely. The minimize and close buttons become very large, title bars are very text heavy in look, and system tray icons are simply scaled up in size giving an aliased and blurry look to them. It’s technically a workable solution, but without extensive developer buy-in, it likely causes as many (or more) problems than it solves.

But Windows XP is now old news, and due to the low PPI displays of the time, it was generally not an issue. DPI scaling in XP was normally used if a person felt the text on the screen was too small, but in almost all cases a better solution was to simply lower the resolution of the monitor, even if it introduced blurriness to the LCD image.

A New Way - DPI Virtualization

Windows Vista introduced a new concept for dealing with applications that are not DPI aware – DPI Virtualization. Below 120 DPI the system would continue to utilize the XP scaling algorithm, but when the DPI settings in Windows are set above 120 DPI, DPI Virtualization is enabled. Any DPI-unaware application that request the DPI setting from the operating system with DPI Virtualization enabled are simply told that the DPI is set at 96 DPI – the base level. Windows then renders the application off screen and then dynamically upscales the application to whatever DPI setting is selected by the user.

While this certainly fixes the issue with fonts falling out of text boxes, it introduces some blurriness to the application. This is not an ideal situation, since the user experience is somewhat compromised. To get around this, Microsoft developed an API to declare that the application is in fact DPI aware on its own. Developers can call SetProcessDpiAwareness to declare that their application is DPI aware, and if so, Windows will not perform any scaling of the application. It’s then up to the application developers to decide how best to handle “non-standard” DPI settings.

Where It All Falls Apart

As with many things in Windows, the operating system is too trusting of developers. Of course not all developers fall into this trap, but many applications in Windows (including many written by Microsoft) don’t follow the best practices on how to deal with High DPI displays. Let’s take a look at one example – VLC player.

VLC 1.0 is what is referred to as a DPI-unaware application. The application was created to render at 96 DPI and it just expects the display to match. This makes the application undersized on a High DPI display, but thanks to DPI Virtualization Windows can automatically scale the application up to match the DPI settings of the display. This does introduce some blurriness to the appearance, but all menu controls and fonts are the correct size for the screen as seen here:

Looking at that image, it’s clearly upscaled but it’s also completely usable. So what’s the issue? VLC is a media player. With DPI Virtualization, media being played back through the application is also rendered at 96 DPI, and then scaled up off screen. This produces a video that appears blurry to the end user, which is not what VLC wants. To correct this issue, the VLC developers changed the application to declare it as System DPI-aware. This disables Windows’ scaling of the application, and Windows expects the application to scale itself. However, in the case of VLC player it doesn’t actually do any scaling at all as you can see in these screen shots of VLC 1.1.1 and the most current version 2.1.3:

Here, any of the UI elements that are handled by the operating system are scaled to the correct DPI settings, but the rest of the application is not scaled at all, which results in an application with unequal proportions. I’m not picking on VLC player here – it is just one of many applications that do exactly the same thing. It’s a great example to show the progression of when a coding choice was made to enable the flag and view the results of the change, as older versions of the software are still readily available. Also in VLC’s favor is the fact that their UI elements are somewhat oversized to start with. This could easily have been a design decision that their application was already usable at High DPI, so it’s not worth scaling the UI at this time.

Let’s look at another application which has long been called out for having issues when Windows is run on a High DPI system – Google Chrome. The oddest thing about Chrome not scaling well is that Chrome does actually support High DPI. Chrome OS, Mac OS X, and obviously the Android versions of Chrome all scale well. But on Windows? There are issues. Here’s a screenshot of Google Chrome taken on my Lenovo Yoga 2 Pro at 3200x1800 with Windows scaling set at 200% (the default setting from the factory):

To see the issues, you’ll likely have to open the full resolution version of that screenshot. At first glance all seems pretty nicely scaled with Chrome – the “chrome” of the browser is not tiny, tabs appear to be the correct size – but look at the actual text on the webpage.

With the cropped image, you can instantly see that the font that Chrome is using is not scaling very well. Text in Chrome on a High DPI system is very poor, and defeats the purpose of using a high resolution screen since you actually lose fidelity rather than gain it.

Chrome, unlike many other apps, does have some workarounds to this issue; unfortunately it’s not something the average computer user would ever be able to figure out. First, you have to open chrome://flags setting page and then enable HiDPI Support Windows. Next, you have to right click the Chrome icon on your desktop, choose properties, and then the configuration tab. Here you need to check the box that says “Disable display scaling on High DPI settings” and apply.

What this checkbox does is actually disable the DPI Virtualization on a per-application basis. Chrome will now use XP style scaling. If you don’t check this box, Chrome will disregard the flag in its own settings, and continue to render text very poorly. The only reason I can think of for Chrome to not use the newer DPI awareness API and instead use the old XP style DPI setting request would be because Chrome is still supported on XP. It’s a strange decision though because running a High DPI system on Windows XP is not a great experience. It’s unfortunate for Chrome users because most of them will never know just how poor of an experience they are getting on newer systems. However, with these changes in place, Chrome now renders correctly.

Next, let’s compare Chrome to an application which does follow best practices – Internet Explorer 11. IE11 correctly queries the operating system for the current DPI setting. When it receives the response, it rescales the UI elements as necessary, and then uses its Zoom feature to enlarge the actual web page. The result is a web page that looks exactly as it should.

IE11 also uses the queried DPI level of the operating system to set the default zoom level, so if you are a heavy keyboard user and you like to use Ctrl+0 to get back to 100% zoom, fear not. This still works, but the default zoom will be a higher number than 100% depending on the scaling factor chosen. Here’s another screenshot of IE11 with the resolution set to 3200x1800 and the DPI set at 96 DPI.

At first glance, it looks hilariously bad, but in fact it is doing exactly what it is supposed to. IE has queried the operating system for the DPI level (now set at 96) and scaled correctly to that level. Not all of Microsoft’s applications do this, but most are not as high profile as Internet Explorer.

When It All Goes Really Wrong

As we’ve seen, Windows can use DPI Virtualization to correct applications that are DPI-unaware, and applications that choose to can opt out of the scaling features and perform their own. But so far we’ve really only seen applications that are slightly out of sync with the developer’s goal. Now it’s time to show some applications that are well and truly broken on High DPI systems.

There are more than this small selection, but the examples I have are all from Adobe. Adobe tends to write its own user interface, which it then can make cross platform. Unlike most applications that use at least some standard Windows tools like Windows Presentation Foundation (WPF) or Windows Forms, almost the entire UI is created by Adobe. As you can imagine, the results are not pretty at 3200x1800 and 200% scaling. First up – the Adobe downloader.

Adobe really wants you to know you are using their product. Even something as simple as an application to download Adobe Reader has its own custom UI. The text box is generally fine, but it's a bit difficult to read. Next is a commonly used application, Adobe Reader XI

Here the file menu is usable, but all of the shortcut icons are tiny. The Tools, Sign, and Comment panels are so small as to be practically unusable. It’s not pretty, and applications like this are a big reason why High DPI Windows systems get knocked during reviews. And our final call out of Adobe’s applications – Photoshop Elements

This application is the worst example of usability on a High DPI system that I’ve seen. Adobe has even replaced the file menu with a custom UI, meaning every single element of this application doesn’t scale at all.

The biggest travesty of Adobe applications not scaling is that their intended market is often media professionals, who are frequently early adopters of things like 4k displays and ultra-high resolution laptops. Hopefully they are working hard on a solution to these issues, but that will also mean anyone using Adobe’s products will likely be forced to update to the latest version – a potentially expensive proposition.

It may seem unfair to specifically call out Adobe, so be aware that there are other applications that also struggle. Remote Desktop sessions can be an issue, with the RDP session rendering at the DPI level of the server, but the resolution of the client. Luckily this has been addressed in the latest versions, but doing RDP sessions or RemoteApp connections to older versions of Windows Server may still be an issue. There are games that likewise have their own launchers that are fully custom and have no scaling (StarCraft II comes to mind), so they end up looking very small on a High DPI system.

Windows 8.1 - More DPI Changes

When Microsoft launched Windows 8.1, it continued to refine the scaling functionality. To assist with people using a tablet such as the Microsoft Surface as a desktop replacement, Windows 8.1 now has the ability to have independent DPI settings per display. This was sorely needed, as anyone who used a Surface Pro (a 1920x1080 pixel 10.6” display) and then connected it to an external 1080p monitor that was two to three times the size of the tablet display complained bitterly about what a terrible experience this was. The Surface Pro’s on-device screen is set at 150% scaling which is necessary to make that resolution work on a 10” screen, but on a 24” monitor all on-screen elements are enormous.

Having two independent DPI settings is not without its challenges. Applications are initially scaled at the DPI setting of whichever monitor they are opened on. With any multi-monitor system, the operating system has to be able to deal with a person moving an application from one monitor to the other. If the application is scaled at the initial DPI, how to you keep it from becoming too large or too small when moved? The solution is once again DPI Virtualization, and once again it’s a solution that works but it’s not ideal.

If the initial monitor is a lower DPI, the application will be scaled up when moved to the higher DPI display, and if it moves from a High DPI monitor to a low DPI display, it will be scaled down. Just like with the Windows Vista DPI Virtualization, this method can result in applications that aren’t as sharp as they should be, as well as quirks with user elements. To get around these issues, Microsoft has expanded the DPI API to allow for per-monitor DPI-aware applications.

Applications that are per-monitor DPI-aware are expected to automatically re-scale themselves when moved between displays. They can do this because the operating system will send a WM_DPICHANGED message to the application when most of the application’s area has moved to a display with a different DPI level. The message sent to the application includes a recommended DPI level, but the application can choose whatever value it wants.

Windows 8.1 also improves several other key elements of DPI settings, continuing the tweaks made since the days of Windows XP where you had to reboot for a DPI change.

All of this DPI talk has focused 100% on the desktop environment. That is because the Modern environment for Windows has the luxury of being built with no legacy applications to deal with, so it can actually work in a manner similar to Apps on iOS and Android.

Windows 8.1 - Windows Store Apps

Love it or hate it, the Modern environment for Windows came at a time when High DPI devices already existed. This allowed it to be architected with support for native scaling for all applications. Windows Store apps are automatically scaled by Windows based on physical screen size, resolution, and device form factor at a ratio of 100%, 140%, and 180%. Windows Store apps encourage the use of scalable vector graphics if possible, or multiple copies of bitmap images to allow crisp images regardless of the scaling used.

Windows Store apps, and even Windows itself, scales not only the DPI of the application, but also how much content the application can display based on the physical screen size. Larger displays, much like in the desktop world, are often used to see and do more on the screen rather than just make everything larger as on a phone, and the Windows Runtime allows for all of this.

Windows Store apps require far less work from the developer in order to achieve this scaling. The app doesn’t have to be DPI aware, because by default all applications automatically are. Instead, things such as XAML layouts and SVG graphics allow the apps to be rescaled completely by the operating system.

Here is Adobe Touch, a Windows Store app version of Adobe Reader. It’s perfectly at home even at 3200x1800 on a 13.3” display. All of the UI elements are correctly sized and of course still usable by touch.

Final Words

Windows has always had the burden of bringing forward legacy APIs and code to allow applications designed for previous versions to continue to operate on newer releases. It also supports a huge number of display sizes, screen resolutions, and form factors. Because of this, it often struggles when major changes are introduced. One such change was the new security model in Windows Vista where (finally) users were no longer administrators by default, and another such change is ultra-high resolution displays with the different goal of improving image quality rather than just increasing usable real estate on the desktop.

Windows 8.1 now officially has three different states for applications: DPI-Unaware, System DPI-Aware, and Per-Monitor DPI-Aware, and solutions are in place to handle all three. It also has a fourth unofficial state: DPI-Unaware masquerading as DPI-Aware applications. Unfortunately there is no current solution for these unofficial applications.

One interim solution would be to have a way to force such applications to scale up, and therefore ignore the DPI-aware flag set in the executable. This would allow DPI Virtualization to scale the applications as needed. This is certainly not ideal, but when you are dealing with a product like Windows with such an enormous catalog of applications, it’s necessary because many of these applications will never be updated to correct scaling issues. The correct solution is to have applications updated to take advantage of the High DPI systems to provide a better user experience, but again this doesn’t really work for legacy applications.

One of the problems holding developers back is that there have been few high resolution devices on the market, meaning few developers would even bother taking the time to correct these issues. Now that there are finally devices from virtually every single computer maker with high PPI panels, there is a market force that will hopefully pressure developers into using best coding practices for scaling DPI.

But what about the current state of things –is it worth avoiding High DPI devices until more applications work properly? My personal experience is no, it’s not worth avoiding them. This will of course depend on what applications you use, but the advantage of a high resolution display is that you can always set the resolution lower if necessary as a workaround on applications like Photoshop. The advantage is that in other applications, you can get very crisp, clear text and a fantastic display for media. Within the next year, I would imagine most major Win32 applications that are actively being developed will have to address these issues. When Apple launched the Retina MacBooks, its catalog of applications took some time to be updated; as that happens for Windows applications, the investment in a High DPI system will make even more sense.

The final piece of the puzzle is the next iteration of Windows. Already shown at BUILD were Modern apps running in a windowed mode on the desktop. These apps will of course have no issues scaling with DPI, providing the ideal “one size fits all” approach to DPI scaling. Figuring out a similar solution for legacy applications on the desktop may be a bit more difficult, but it’s certainly something Microsoft is working to address. Time will tell how well they manage to do so.

Sources:

http://blogs.windows.com/windows/b/extremewindows/archive/2013/07/15/windows-8-1-dpi-scaling-enhancements.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/dd464659(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx