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.

History of Windows DPI Scaling When It All Goes Really Wrong
POST A COMMENT

114 Comments

View All Comments

  • microlithx - Wednesday, April 16, 2014 - link

    Now if only the Modern environment wasn't a walled garden, I would support what you're saying. Unfortunately, I can't get behind ignoring the desktop for high DPI in the future so long as Microsoft tries to mimic Apple's lock down fetish. Reply
  • Imaginer - Tuesday, April 15, 2014 - link

    I have complained about AutoCAD not scaling properly under 1080p resolutions and at 125% scaling or even 150%. But I believed Autodesk listened since, because on my Surface Pro (and Pro 2), I haven't had an issue with their ribbons or layout.

    The only minor complaint, is their help and search minibar cannot be moved and it obscures the minimize and maximize buttons on their main AutoCAD window.
    Reply
  • nportelli - Tuesday, April 15, 2014 - link

    PC screen DPI took a hit when "HD" TV's came out. I had a 15" 1920x1200 laptop, after HDTV became popular I could barely find a 15" 1080p laptop. My old CRT monitor ran in a '4k' resolution. None of this is new, we've just been set back about 10 years due to people thinking 768p screens are acceptable. Reply
  • phoenix_rizzen - Tuesday, April 15, 2014 - link

    Exactly. There's a reason Windows 9x, WinNT 4-XP all came with two default values for DPI: 96 and 120. 120 DPI screens have been around since the CRT days, and using 120 DPI setting in Windows on a 120 DPI CRT was a very pleasant experience. Granted, some of those displays were 75-100 lbs behemoths, but they were around.

    Once LCDs started taking off, 720p and 1080p with <100 DPI become "the norm" and everything stagnated there for a decade or so. :(

    Considering the timelines, there's really no excuse other than laziness for why things don't work in a resolution-independent fashion ~30 years after the release of Windows 95.
    Reply
  • azazel1024 - Tuesday, April 15, 2014 - link

    This is actually part of the reason why I really like my T100 and its 768p resolution. With a 10.1" screen, the ~155dpi to my eye is pretty darned good with 100% scaling. Much higher DPI and everything gets too small without scaling and, sadly, I use plenty of those Adobe applications on a regular basis.

    I certainly wouldn't mind if my laptop and desktop displays were a wee closer to 150dpi also (14" 768p and 23" 1080p respectively). Or, say, 140ish dpi for the laptop and 120ish dpi for the monitor would probably "perfect" to my eye, until MS/Windows gets around the scaling issues with legacy applications.
    Reply
  • Imaginer - Tuesday, April 15, 2014 - link

    One other thing about UI adherence, is that some software developers may not take advantage of the touch scrolling aspects that I found you can do with things like File explorer windows and some browsers (Opera).

    I am giving you the evil eye Valve's Steam. Your UI for the longest time only had a fixed scaling, not being able to keep with the OS's DPI scaling. Thus your excuse for that "Big Picture" mode that is SLOW (at my initial trying and at times still is now). If you could just tune that scaling, it would be fine for a wireless trackball and keyboard HTPC setup (and maybe some mouses that work on couch cushions...).
    Reply
  • yhselp - Friday, April 18, 2014 - link

    Yes, Steam. Steam... The UI is so small even on a 23" 1080p monitor that it's practically unusable. Hundreds of thousands of people strain their eyes on a daily basis and Valve haven't done anything about it, all these years. Given how much money they make off it and the high profile of the application it seems ludicrous. Reply
  • eSyr - Tuesday, April 15, 2014 - link

    > APIs to retrieve monitor DPI No No No No Yes
    Ehrrr, WHAT. How about GetDeviceCaps() ( http://msdn.microsoft.com/en-us/library/dd144877%2... ) with nindex set to HORZSIZE or VERTSIZE. This is part of WinAPI since. like, forever.
    Reply
  • Brett Howse - Tuesday, April 15, 2014 - link

    That's the old XP style - you need to read your entire link:
    Note GetDeviceCaps reports info that the display driver provides. If the display driver declines to report any info, GetDeviceCaps calculates the info based on fixed calculations. If the display driver reports invalid info, GetDeviceCaps returns the invalid info. Also, if the display driver declines to report info, GetDeviceCaps might calculate incorrect info because it assumes either fixed DPI (96 DPI) or a fixed size (depending on the info that the display driver did and didn’t provide). Unfortunately, a display driver that is implemented to the Windows Display Driver Model (WDDM) (introduced in Windows Vista) causes GDI to not get the info, so GetDeviceCaps must always calculate the info.

    So it's a calculated value and not always accurate. The new API uses Extended display identification data (EDID) to provide the actual screen size. This specific API for the monitor DPI rather than system DPI is new to Windows 8.1.
    Reply
  • bji - Wednesday, April 16, 2014 - link

    Why couldn't Microsoft have updated the old GetDeviceCaps API to use the EDID data internally so that it could be more accurate in more situations, as well as providing a new API with more detail as well? Or maybe it did and its documentation is now out of date? Reply

Log in

Don't have an account? Sign up now