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