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.

Scaling Windows - Introduction Where It All Falls Apart
POST A COMMENT

114 Comments

View All Comments

  • pixelstuff - Tuesday, April 15, 2014 - link

    Not to mention, apparently Adobe has created a HiDPI interface for OSX. So it's not exactly like they are having to reinvent the wheel on Windows. Reply
  • jamyryals - Tuesday, April 15, 2014 - link

    Most developers are doing what was scoped for a project. DPI scaling was not very important for many years. It was difficult to assign resources to a problem when it was an issue that few encountered. Believe it or not, but most decisions in development are based on priority and not laziness. Go ahead and keep shaking your fist at them though, you'll show 'em! Reply
  • eddman - Tuesday, April 15, 2014 - link

    Are you one of such developers, because I don't see how anyone can defend such practices.

    There are these things called guidelines. You don't need to have project "scopes" or resources to follow them. If a developer doesn't care to follow such basic things, then he/she doesn't deserve any respect.
    Reply
  • npaladin2000 - Tuesday, April 15, 2014 - link

    When your project manager says "don't bother programming for DPI scaling, we don't have the time, and we have to meet this deadline in order to get paid on time" then you skip the frigging DPI scaling. Get it? Reply
  • eddman - Tuesday, April 15, 2014 - link

    They would actually demand it?! Is it really that hard to code a DPI-aware program? I have a hard time believing the latter.

    If it is easy and yet they still ignore, then it is even worse than I thought.
    Reply
  • inighthawki - Wednesday, April 16, 2014 - link

    Again, I see you don't work in the software industry. Every feature takes time. If that time is not in the current milestone budget, it gets cut. So yes, it happens, and your project manager absolutely can demand you not work on it. Reply
  • Alexey291 - Wednesday, April 16, 2014 - link

    Sometimes I wonder if any of the people here have ever worked in ANY industry let alone as developers.

    Every project in the damn world has a set of priorities and you don't "just decide" to throw something in unless you're told to.
    Reply
  • Gigaplex - Wednesday, April 16, 2014 - link

    Yes, it really is that hard to code DPI-awareness into a Win32 application. The API is horrendous. Reply
  • UsernameAlreadyExists - Wednesday, April 16, 2014 - link

    Thus, since around 2007 (2006-2008?) writing Windows applications with WPF has been possible..

    "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."

    XAML, since 2008 or so has allowed the programs to be rescaled completely by the operating system. Might have been nice to mention this in the article.
    Reply
  • Klimax - Thursday, April 17, 2014 - link

    If it is hard for you and like, then don't do UI yourself and use bloody framework or toolkit.

    Anyway:
    http://msdn.microsoft.com/en-us/library/windows/de...
    Tutorial:
    http://msdn.microsoft.com/en-us/library/windows/de...

    And I am sure similar docs were there for all those years...
    Reply

Log in

Don't have an account? Sign up now