Scaling Windows - The DPI Arms Race
by Brett Howse on April 15, 2014 2:00 PM EST- Posted in
- Operating Systems
- Windows
- Microsoft
- Windows 8.1
- 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.
Facebook
Twitter
RSS
114 Comments
View All Comments
inighthawki - Tuesday, April 15, 2014 - link
I take it you're not a developer? Or else you'd understand at large companies you have a set of tasks, a time limit, and you have to cut certain features and prioritize them to customer needs. In Adobe's case, maybe, despite what you may think, their research showed that few people needed a high DPI UI, so resources were spent on other features first.npaladin2000 - Tuesday, April 15, 2014 - link
Yes I am a developer, working for a large multinational ecommerce provider. And I just said exactly what you did only I was much coarser and simpler in my language in the hopes that it will penetrate some of the thicker skulls out there. But the bottom line is that you apply hours to the features that are either functionally required, contractually required, or will actually be used. If something's unlikely to be used or isn't a specifically requested feature, it's not going to get resources spent on it. Why would you? That would essentially be throwing away money. Those hours could be spent on something else that will actually generate revenue instead.Murloc - Tuesday, April 15, 2014 - link
he was answering to eddman, not you, look at the comment indentation.inighthawki - Tuesday, April 15, 2014 - link
I was replying to eddman. Anandtech's comments section could use a small upgrade. After like 4 levels of replies it's impossible to tell who is replying to whom.JDG1980 - Tuesday, April 15, 2014 - link
You're missing the point. You have to *actively do something wrong* for DPI scaling to not work properly. The standard guidelines for Windows API programming have included support for HiDPI for years. If you don't have time to program your own custom controls that support HiDPI, then use the standard controls. If you have time to reinvent the wheel for your project, then you have time to do it right.Gigaplex - Wednesday, April 16, 2014 - link
"If you have time to reinvent the wheel for your project, then you have time to do it right."I wish this was true, however it's not. As deadlines loom, you do whatever you need to in order to get it to work. It would be nice to use standard controls for everything, but they aren't flexible enough for that.
darthrevan13 - Wednesday, April 16, 2014 - link
Then why set the flag to true? So that there would be more problems?Zoomer - Monday, April 21, 2014 - link
Same issue with VLC - fidelity in rendering the work is essential. Small UI vs your artwork rendered wrong - not hard to see what customers will choose. Many pros already memorized the keyboard shortcuts anyway.twtech - Tuesday, April 15, 2014 - link
If you are ever involved with software development, one of the things you will learn is that there is always more to do, and there will always be more to do than you can ever get done. So you must prioritize what you're going to work on.If you want to devote the time to DPI scaling, that means something else that you could be doing is not going to get done. When most displays were all roughly around the same PPI, it just didn't make sense to prioritize DPI scaling highly relative to other work.
phoenix_rizzen - Tuesday, April 15, 2014 - link
Yeah. Everyone seems to forget that before LCDs took over and relegated us to a wasteland of 720p and 1080p panels, hi-resolution and hi-dpi monitors were commonplace. 1600x1200 was common in the 90s, and usually under/around 20". 1280x1024 was even more common at 14-17".Don't feel like doing the math on those, but they should be over 100 DPI.