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

  • weebnuts - Wednesday, April 16, 2014 - link

    Thanks for the Google Chrome tip, it used to scale fine until a month or so ago, they must have changed things in the new versions when the new windows 8.1 update was released. Reply
  • Icehawk - Wednesday, April 16, 2014 - link

    I just ran into this issue this week when I added a Dell 27" to my family of older 19x12 16:10 monitors - aside from the aspect ratio change in order to use the new Dell as my main monitor I need scaling or the text is too small - now my old monitors are cartoonishly large. Was hoping to skip W8 but will try W8.1U1 and see if it works better with the different DPI levels and doesn't drive me insane with Metro, ahem, I mean Modern. Reply
  • kgh00007 - Wednesday, April 16, 2014 - link

    Cheers for the tip on Chrome, it looks way better now on Win 8.1 on my 40" 1080p TV! Reply
  • fokka - Wednesday, April 16, 2014 - link

    i'm really thankful for the article shedding more light at this topic, maybe this will bring more developers to update their programs to feature better hidpi-skaling. Reply
  • vlad0 - Thursday, April 17, 2014 - link

    Great talk on DPI @ build2014

    http://channel9.msdn.com/Events/Build/2014/2-535
    Reply
  • liffie420 - Thursday, April 17, 2014 - link

    This is not really a comment on the article itself but something that the screen shots bring up dealing with web pages. This does not apply to all pages however, but with most people using a widescreen display (we are talking at least %95 at this point) regardless of actual resolution why is it that we page developers can not manage to scale the page elements to wide screen?? Having done a very small amount of hand coding html back in the day (16ish years ago) I know you want to aim for the LCD to be sure your pages load correctly on all browsers and across connection types. But why is it you can't fill the sides os your browser window with the actual site. Im in the newest chrome browser with a 22" lcd at 1080P yet the site itself only falls in the middle leaving a couple inches of screen empty. Yes you can F11 in most browsers and full screen but that still rarely fixes the issue. Just a pet peeve of mine is all. Reply
  • dorekk - Saturday, June 21, 2014 - link

    Because very wide lines of text are extremely awkward to read, so it's much better to make the text area of a website look roughly like a portrait-oriented piece of paper. Reply
  • Androidtech - Thursday, April 17, 2014 - link

    I find it rather perplexing that a mobile operating system like Android is more capable at scaling resolutions than something as old as windows. I thought things are supposed to get better with age and experience. Oh well at least this summer we will have some new code for websites to scale properly ! Reply
  • caywen - Friday, April 18, 2014 - link

    In actuality, IE11 on Windows 8.1 isn't clear of these problems when doing multi-monitor. I have a Yoga 2 Pro connected to a 24" 1080p display. IE11 looks beautiful on the Y2P display, but when moved to the 24" display, the whole UI becomes enormous. The title bars are almost 1" thick! Clearly, Microsoft still have a few hurdles.

    Other windows, when dragged between displays, instantly snap to their "normal" size on that display, but the effect is strange.

    I think what they ought to do is:
    - Support high-DPI virtualization where applications can advertise that they support, say, 200 or 300dpi. The author can then write their app specifically to that. Windows could then do the same DPI virtualization, but the scaling would then be much sharper (and almost always downwards).
    - Draw *only* from the virtual buffer to each display. That way, there would be no snapping effect - just the app always being the right size even when between displays.
    - Create a virtual buffer at the highest DPI of all the connected monitors and have 96dpi apps draw scaled-up into that buffer. The difference would be that text draw calls would draw at the native size rather than at 96dpi. At least the text in these apps would be razor sharp, if not the icons and other things.
    Reply
  • AnnonymousCoward - Saturday, April 19, 2014 - link

    The name "retina display" doesn't even make sense, because a retina senses light. Apple just went with "[some word associated with vision] display". Reply

Log in

Don't have an account? Sign up now