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