High-DPI awareness has been the subject of the presentation that i held with Mike Swingler at this year’s JavaOne. This topic has not been getting nearly as much attention as it deserves to, but things might change in the near future.

Ryan Haveson is the program manager lead for the Desktop Graphics team of Windows 7 (the next version of Windows OS). In the article published a few days ago on Windows 7 blog he delves into such areas as scaling modes, programmatic support, current configurations and future plans. One of the main considerations for Windows as the current leader in the desktop presence is backwards compatibility. Ryan’s team must find the right balance between addressing the modern high-resolution hardware and not breaking user experience for older applications:

Our thinking for Windows 7 was that if we enable high DPI out of the box on capable displays, we will enable users to have a full-fidelity experience and also significantly reduce eye strain for on-screen reading. There is even infrastructure available to us to detect a display’s native DPI so we can do a better job of configuring default settings out of the box. However, doing this will also open up the door to expose some issues with applications which may not be fully compatible with high DPI configurations.

As it stands now, applications using GDI have to explicitly scale the visuals:

One of the issues is that for GDI applications to be DPI aware, the developer must write code to scale the window frame, text size, graphical buttons, and layout to match the scaling factor specified by the DPI setting. Applications which do not do this may have some issues. Most of these issues are minor, such as mismatched font sizes, or minor layout artifacts, but some applications have major issues when run at high DPI settings.

While Vista (as well as XP) provide automatic scaling, this results in blurry visuals that do not utilize the full potential of high-resolution monitors:

In the case of automatic scaling, applications which are not DPI aware are automatically scaled by the window manager. The text size matches the user preference, but it also introduces a blurry effect for that application’s window as a result.

It is not clear from this posting what are the exact plans for the next Windows release. The conclusion section is very uncommitting and vague, but it is very encouraging to see that Microsoft is joining Apple and KDE / Gnome in providing tools to scale the UIs to match the current desktop hardware. In fact, the upcoming release 8 of Internet Explorer boasts full support for High DPI mode (though the quote on “entire awareness” of Vista is exaggerated as can be seen from the screenshots in our JavaOne presentation):

Like Windows Vista, the Internet Explorer 8 UI is entirely Hi-DPI Aware. You will also notice that all UI elements and UI fonts are scaled accordingly and that icons are larger and have higher fidelity. Notice the difference in the Internet Explorer chrome when Windows DPI Scaling is set to 96 DPI and 120 DPI, respectively:

Internet Explorer Chrome at 96 DPI.

Internet Explorer Chrome at 120 DPI.

It is quite illuminating to read the comments on this entry. Some readers call for the monitor manufacterers to effectively stop the progress and agree on a fixed pixel size:

The physical size in inches should be proportional to resolution in pixels. If [manufacterers] increase the resolution without making the screen larger, it’s obvious that we have problems for reading! I don’t think Microsoft should modify Windows because monitor makers are doing silly things. There should be an international standard for pixel size and font readability.

And going even further to follow Apple’s route:

MAC App developers don’t have to worry about DPI or non-square pixels because Apple has full control over the specification of the MAC monitors. Why Windows can’t do the same and completely remove the scaling burden from app developers? Microsoft should use its influence on PC manufacturers and ask them to build monitors to Windows certified specification.

One reader points to a bit of a chicken-and-egg problem:

Programmers don’t bother with DPI aware apps, because all mainstream monitors have their physical DPI @ 96. And monitor makers don’t bother with making bigger DPI monitors, because apps aren’t there yet. The only solution I see, is to bite the bullet and at default make Windows adjust to the native resolution/DPI.

And a sane voice points to a solution that does not involve user intervention at all, hiding the pixel-point-inch impedance behind the scenes:

Windows 7 should automatically set your monitor at its native resolution. It should then determine the best dpi for your display and automatically scale the entire OS to it, afterwards if you want to set it at a different dpi then you can.

While the hardware technology of high-resolution monitors does not progress at nearly the same rate as other parts of the consumer-oriented market (CPU, GPU, RAM, hard disk, etc), it is evolving nonetheless. The major operating systems and windowing toolkits differ in their level of support. Hopefully, Microsoft’s awareness of the importance of this subject will not be significantly hampered by the shackles of backwards compatibility.