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
Final Words
Windows has always had the burden of bringing forward legacy APIs and code to allow applications designed for previous versions to continue to operate on newer releases. It also supports a huge number of display sizes, screen resolutions, and form factors. Because of this, it often struggles when major changes are introduced. One such change was the new security model in Windows Vista where (finally) users were no longer administrators by default, and another such change is ultra-high resolution displays with the different goal of improving image quality rather than just increasing usable real estate on the desktop.
Windows 8.1 now officially has three different states for applications: DPI-Unaware, System DPI-Aware, and Per-Monitor DPI-Aware, and solutions are in place to handle all three. It also has a fourth unofficial state: DPI-Unaware masquerading as DPI-Aware applications. Unfortunately there is no current solution for these unofficial applications.
One interim solution would be to have a way to force such applications to scale up, and therefore ignore the DPI-aware flag set in the executable. This would allow DPI Virtualization to scale the applications as needed. This is certainly not ideal, but when you are dealing with a product like Windows with such an enormous catalog of applications, it’s necessary because many of these applications will never be updated to correct scaling issues. The correct solution is to have applications updated to take advantage of the High DPI systems to provide a better user experience, but again this doesn’t really work for legacy applications.
One of the problems holding developers back is that there have been few high resolution devices on the market, meaning few developers would even bother taking the time to correct these issues. Now that there are finally devices from virtually every single computer maker with high PPI panels, there is a market force that will hopefully pressure developers into using best coding practices for scaling DPI.
But what about the current state of things –is it worth avoiding High DPI devices until more applications work properly? My personal experience is no, it’s not worth avoiding them. This will of course depend on what applications you use, but the advantage of a high resolution display is that you can always set the resolution lower if necessary as a workaround on applications like Photoshop. The advantage is that in other applications, you can get very crisp, clear text and a fantastic display for media. Within the next year, I would imagine most major Win32 applications that are actively being developed will have to address these issues. When Apple launched the Retina MacBooks, its catalog of applications took some time to be updated; as that happens for Windows applications, the investment in a High DPI system will make even more sense.
The final piece of the puzzle is the next iteration of Windows. Already shown at BUILD were Modern apps running in a windowed mode on the desktop. These apps will of course have no issues scaling with DPI, providing the ideal “one size fits all” approach to DPI scaling. Figuring out a similar solution for legacy applications on the desktop may be a bit more difficult, but it’s certainly something Microsoft is working to address. Time will tell how well they manage to do so.
Sources:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd464659(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx
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?