Problem solve Get help with specific problems with your technologies, process and projects.

Anniversary Update Display Scaling Changes

Build 1607 for Windows 10 released earlier this month introduces some interesting changes. I seldom jump exclusively on a Microsoft blog post for blog fodder, but today is an exception. This August 16 item comes from the MS Enterprise Platforms Support Ask the Core Team blog. It deals with Anniversary Update display scaling changes. In fact, this post offers a detailed and thorough description of issues involved in display scaling. It also explains how the Anniversary Update addresses some of them. The post is entitled “Display Scaling changes for the Windows 10 Anniversary Update.” Its author is James Burrage (Senior Support Escalation Engineer, MSFT), and it’s worth reading from stem to stern.

High Points: Anniversary Update Display Scaling Changes

To begin, Burrage links to an earlier post to the same blog entitled “Display Scaling in Windows 10.” It sets the stage and explains the background against which this post works. Thus, it too, is worth reading.

Burrage’s opening problem statement reads (quoted verbatim):

  1. Blurry text and UI components.
  2. Applications sized incorrectly (too big or too small)
  3. Applications are sized correctly and are not blurry, but have other layout issues …

Burrage provides a nice illustration to depict the foregoing issues.

He explains such issues are likely when the display scale factor on a Windows PC changes while a user is logged in. A typical case is when an application moves from a “main display” to another display with a different scale factor. I’ve seen this happen myself. I see it when my Surface Pro 3 is docked, and I switch from the high-res built-in screen to a lower-res external monitor. The stretching and blurriness issues match my experience exactly.

Burrage explains that application development models have, until recently, treated display factors as unchanging constants. That is, once they’re acquired as an application gets up and running, the assumption is that they won’t change. Alas, that is not the way the world in which we now live and work actually behaves. And while it may not be a problem for new applications that build in necessary intelligence (or draw on it from readily available APIs), it is an issue for legacy applications not designed that way.

What Can Developers Do About Anniversary Update Display Scaling?

Burrage explains how Windows developers tackled this issue  to update “the Windows File Explorer application to dynamically handle a display-scale-factor change.” It makes for fascinating reading, and illuminates the group’s learning process. Many developers seeking to update their own applications accordingly will face similar issues.

He explains how new code in the AU handles this for “parts of a typical desktop application window that the application itself does not draw…” This includes titles, captions, system menus, scrollbars, and more. It is called the non-client area (NCA) , now handled through a new EnableNonClientDpiScaling API. He also explains how mixed-mode DPI scaling lets developers focus scaling efforts where they matter most. That API is called SetThreadDpiAwarenessContext. He also talks about Office, the Windows Presentation Framework (WPF), and some other issues that AU did NOT address. These include desktop icon scaling, common control scaling and WinForms, plus log-out/log-in following display factors changes.

This is a nice piece of work. Again, for those interested in Windows UI issues (or who develop Windows apps) this is must-read stuff. If you want to understand changes to Anniversary Update display scaling, this is just the thing!

[Note: thanks very much to leader Shawn Brink, whose News Forum post this morning took my feet down the information path that let to this blog item. Keep up the great work, Shawn: we appreciate it!]