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
When It All Goes Really Wrong
As we’ve seen, Windows can use DPI Virtualization to correct applications that are DPI-unaware, and applications that choose to can opt out of the scaling features and perform their own. But so far we’ve really only seen applications that are slightly out of sync with the developer’s goal. Now it’s time to show some applications that are well and truly broken on High DPI systems.
There are more than this small selection, but the examples I have are all from Adobe. Adobe tends to write its own user interface, which it then can make cross platform. Unlike most applications that use at least some standard Windows tools like Windows Presentation Foundation (WPF) or Windows Forms, almost the entire UI is created by Adobe. As you can imagine, the results are not pretty at 3200x1800 and 200% scaling. First up – the Adobe downloader.
Adobe really wants you to know you are using their product. Even something as simple as an application to download Adobe Reader has its own custom UI. The text box is generally fine, but it's a bit difficult to read. Next is a commonly used application, Adobe Reader XI
Here the file menu is usable, but all of the shortcut icons are tiny. The Tools, Sign, and Comment panels are so small as to be practically unusable. It’s not pretty, and applications like this are a big reason why High DPI Windows systems get knocked during reviews. And our final call out of Adobe’s applications – Photoshop Elements
This application is the worst example of usability on a High DPI system that I’ve seen. Adobe has even replaced the file menu with a custom UI, meaning every single element of this application doesn’t scale at all.
The biggest travesty of Adobe applications not scaling is that their intended market is often media professionals, who are frequently early adopters of things like 4k displays and ultra-high resolution laptops. Hopefully they are working hard on a solution to these issues, but that will also mean anyone using Adobe’s products will likely be forced to update to the latest version – a potentially expensive proposition.
It may seem unfair to specifically call out Adobe, so be aware that there are other applications that also struggle. Remote Desktop sessions can be an issue, with the RDP session rendering at the DPI level of the server, but the resolution of the client. Luckily this has been addressed in the latest versions, but doing RDP sessions or RemoteApp connections to older versions of Windows Server may still be an issue. There are games that likewise have their own launchers that are fully custom and have no scaling (StarCraft II comes to mind), so they end up looking very small on a High DPI system.
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.