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
Windows 8.1 - More DPI Changes
When Microsoft launched Windows 8.1, it continued to refine the scaling functionality. To assist with people using a tablet such as the Microsoft Surface as a desktop replacement, Windows 8.1 now has the ability to have independent DPI settings per display. This was sorely needed, as anyone who used a Surface Pro (a 1920x1080 pixel 10.6” display) and then connected it to an external 1080p monitor that was two to three times the size of the tablet display complained bitterly about what a terrible experience this was. The Surface Pro’s on-device screen is set at 150% scaling which is necessary to make that resolution work on a 10” screen, but on a 24” monitor all on-screen elements are enormous.
Having two independent DPI settings is not without its challenges. Applications are initially scaled at the DPI setting of whichever monitor they are opened on. With any multi-monitor system, the operating system has to be able to deal with a person moving an application from one monitor to the other. If the application is scaled at the initial DPI, how to you keep it from becoming too large or too small when moved? The solution is once again DPI Virtualization, and once again it’s a solution that works but it’s not ideal.
If the initial monitor is a lower DPI, the application will be scaled up when moved to the higher DPI display, and if it moves from a High DPI monitor to a low DPI display, it will be scaled down. Just like with the Windows Vista DPI Virtualization, this method can result in applications that aren’t as sharp as they should be, as well as quirks with user elements. To get around these issues, Microsoft has expanded the DPI API to allow for per-monitor DPI-aware applications.
Applications that are per-monitor DPI-aware are expected to automatically re-scale themselves when moved between displays. They can do this because the operating system will send a WM_DPICHANGED message to the application when most of the application’s area has moved to a display with a different DPI level. The message sent to the application includes a recommended DPI level, but the application can choose whatever value it wants.
Windows 8.1 also improves several other key elements of DPI settings, continuing the tweaks made since the days of Windows XP where you had to reboot for a DPI change.
| High DPI Windows Features | |||||
| Feature | Windows XP | Windows Vista | Windows 7 | Windows 8 | Windows 8.1 |
| DPI Virtualization of DPI-unaware apps | No | Yes | Yes | Yes | Yes |
| DPI Virtualization of System DPI-aware apps | No | No | No | No | Yes |
| API to declare DPI awareness level | No | Yes | Yes | Yes | Yes |
| API to declare per-monitor DPI awareness | No | No | No | No | Yes |
| APIs to retrieve system metrics and DPI | Yes | Yes | Yes | Yes | Yes |
| Window notification of DPI change | No | No | No | No | Yes |
| APIs to retrieve monitor DPI | No | No | No | No | Yes |
| Requires reboot for monitor DPI change | N/A | N/A | N/A | N/A | No |
| Requires a reboot/log off for system DPI change | Reboot | Reboot | Log off | Log off | Log off |
| Per user DPI setting | No | No | Yes | Yes | Yes |
| Auto configuration of DPI at first logon | No | No | Yes | Yes | Yes |
| Viewing distance incorporated in default DPI calculation | No | No | No | No | Yes |
All of this DPI talk has focused 100% on the desktop environment. That is because the Modern environment for Windows has the luxury of being built with no legacy applications to deal with, so it can actually work in a manner similar to Apps on iOS and Android.
Windows 8.1 - Windows Store Apps
Love it or hate it, the Modern environment for Windows came at a time when High DPI devices already existed. This allowed it to be architected with support for native scaling for all applications. Windows Store apps are automatically scaled by Windows based on physical screen size, resolution, and device form factor at a ratio of 100%, 140%, and 180%. Windows Store apps encourage the use of scalable vector graphics if possible, or multiple copies of bitmap images to allow crisp images regardless of the scaling used.
Windows Store apps, and even Windows itself, scales not only the DPI of the application, but also how much content the application can display based on the physical screen size. Larger displays, much like in the desktop world, are often used to see and do more on the screen rather than just make everything larger as on a phone, and the Windows Runtime allows for all of this.
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.
Here is Adobe Touch, a Windows Store app version of Adobe Reader. It’s perfectly at home even at 3200x1800 on a 13.3” display. All of the UI elements are correctly sized and of course still usable by touch.
Facebook
Twitter
RSS
114 Comments
View All Comments
JDG1980 - Tuesday, April 15, 2014 - link
Adobe is a company full of whiners. When the Surface Pro came out, the pen didn't work in Photoshop because it used the Microsoft Ink API, instead of WinTab. (WinTab was supposed to be a free standard, but is tied up by a patent troll.) When Adobe was asked to fix this, they said "Waaaah, Ink API is too hard and we don't like it, so MS will have to support the old API instead." Unfortunately, Microsoft backed down instead of forcing Adobe to do the right thing. And we're seeing this same thing again with HiDPI support for Windows: "Waaah, it's too hard, we don't like the APIs, please Microsoft fix it for us". It's been pointed out to them multiple times that many other apps manage to do it just fine, but no, Adobe is a special snowflake and it has to be their way. Everyone else has to conform to them. Can't expect them to do any real work for the thousands of dollars per unit that they're being paid by graphics professionals.jhoff80 - Tuesday, April 15, 2014 - link
That had been a problem for nearly a decade. However, Adobe has now added Ink API support to Illustrator and Photoshop in their newest updates.And while I definitely fault Adobe for taking so long to add the Ink API, Microsoft still needed to get a Wintab driver. Adobe is not the only company that wasn't (at the time) using the Ink API. Even now, Photoshop is covered, sure. That doesn't help with Mischief, or 3D modeling programs, or any number of other Wintab-only applications.
Imaginer - Tuesday, April 15, 2014 - link
You do not need to wait for a Microsoft WinTab driver. Wacom's FeelIT drivers for Tablet PCs has been updated for the Pros since last year around May.And, the drivers work for any Wacom pen-enabled displays. This driver, allows me to have two side buttons to assign functions and work with on particular pens out there (most definitely not the Surface Pen).
jhoff80 - Tuesday, April 15, 2014 - link
Yes, that is exactly the driver we were talking about waiting for. That issue is fixed now on both ends. Microsoft/Wacom have their Wintab driver, and Adobe now also supports the Ink API. But when the Surface Pro first came out, neither of those things were true.twtech - Tuesday, April 15, 2014 - link
In an ideal world, every huge old codebase like Photoshop's would be very clean, and adding another pen interface would be relatively straightforward.In reality, they probably had WinTab-specific code sprinkled in there in various places, which made fixing the problem more difficult, and includes the possibility that the WinTab stuff wouldn't work right afterward if any mistakes were made during the process of making that code generic.
JDG1980 - Wednesday, April 16, 2014 - link
Well, that's why we pay them the big bucks. It's their responsibility to keep their code base clean and maintainable, not everyone else's responsibility to pander to their pile of spaghetti code.kasakka - Sunday, April 20, 2014 - link
My experience with Adobe is that while the guys working on the image manipulation algorithms are absolutely brilliant, the folks behind the UI and QA are borderline incompetent. Adobe's software has been riddled with a shitload of small UI flaws (ranging from wrong fonts to incorrectly positioned controls to more severe stuff) for years and they don't seem to bother doing anything about it. These are probably the same people we can thank for not having proper DPI scaling.skiboysteve - Tuesday, April 15, 2014 - link
Great article. Kudos on writing this up so clearlyr3loaded - Tuesday, April 15, 2014 - link
The problem is that developers for the Mac are far more enthusiastic and invested in their platform, so when the rMBP was launched many of the big names rushed to add HiDPI support to their programs (either straight out of the gate or within a couple of months), giving a good user experience. There's also a general culture of following Apple's guidelines on UI design and UX best practices.On the Windows side, many developers can't give a crap about UX problems and blatantly ignore Microsoft's guidelines and best practices, preferring to do it their way. They still haven't got around to fixing their programs. I wonder if many ever will.
Unless there's a big shift in culture and attitude, we're going to continue seeing scaling issues in Windows programs (issues that are in reality the fault of developers, not Windows itself).
jhoff80 - Tuesday, April 15, 2014 - link
To be honest, this is exactly why I feel that Metro needed (and still needs) to continue being pushed forward, as much as most power users hate it. Sure, there are some great desktop / Win32 apps, but they haven't really been relevant for years, and most developers just don't care enough any more to update them in really essential ways for the future (High DPI being the prime example). WinRT / Metro definitely still are rough around the edges, but in forcing developers to cut ties, it also forces a lot of progress on these fronts.