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
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.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.
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.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.
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.
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...).
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.eSyr - Tuesday, April 15, 2014 - link
> APIs to retrieve monitor DPI No No No No YesEhrrr, 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.
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.
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?