Engineering Windows 7

Welcome to our blog dedicated to the engineering of Microsoft Windows 7

Follow-up on High DPI resolution

Follow-up on High DPI resolution

  • Comments 73

One of the cool results of this dialog is how much interest there is in diving into the details and data behind some of the topics as expressed in the comment and emails.  We’re having fun talking in more depth about these questions and observations.  This post is a follow-up to the comments about high DPI resolution, application compatibility, and the general problems with readability in many situations.  Allow me to introduce a program manager lead on our Desktop Graphics team, Ryan Haveson, who will expand on our discussion of graphics and Windows 7.  –Steven

When we started windows 7 planning, we looked at customer data for display hardware, and we found something very interesting (and surprising). We found that roughly half of users were not configuring their PC to use the full native screen resolution. Here is a table representing data we obtained from the Windows Feedback Program which Christina talked about in an earlier post.

Table showing that 55% of those with higher definition monitors lower their resolution.

We don't have a way of knowing for sure why users adjust their screen resolution down, but many of the comments we’ve seen match our hypothesis that a lot of people do this to because they have difficulty reading default text on high resolutions displays.  With that said, some users probably stumble into this configuration by accident; for example due to a mismatched display driver or an application that changed the resolution for some reason but did not change it back. Regardless of why the screen resolution is lower, the result is blurry text that can significantly increase eye fatigue when reading on a PC screen for a long period of time. For LCD displays, much of the blurriness is caused by the fact that they are made up of fixed pixels. In non-native resolution settings, this means that the system must render fractional pixels across fixed units, causing a blurred effect. Another reason for the relative blurriness is that when the display is not set to native resolution, we can’t properly take advantage of our ClearType text rendering technology , which most people (though not all) prefer. It is interesting to note that the loss of fidelity due to changing screen resolution is less pronounced on a CRT display than on an LCD display largely because CRTs don’t have fixed pixels the way that LCDs do. However, because of the advantages in cost and size, and the popularity of the laptop PC, LCD displays are fast gaining market share in the installed base. Another problem with running in a non-native screen resolution is that many users inadvertently configure the display to a non-native aspect ratio as well. This results in an image that is both blurry and skewed! As you can imagine, this further exacerbates the issues with eye strain.

Looking beyond text, in these scenarios the resulting fidelity for media is significantly reduced as well. With the configuration that many users have, even if their hardware is capable, they are not able to see native “high def” 720p or 1080p TV content, which corresponds to 1280x720 and 1920x1080 screen resolutions respectively. The PC monitor has traditionally been the “high definition” display device, but without addressing this problem we would be at risk of trailing the TV industry in this distinction. While it is true that only about 10% of users have a truly 1080p capable PC screen today, as these displays continue to come down in price the installed base is likely to continue to grow. And you can bet that there will be another wave of even higher fidelity content in the future which users will want to take advantage of. As an example, when displays get to 400 DPI they will be almost indistinguishable from looking at printed text on paper. Even the current generation of eBook readers with a DPI of ~170 look very much like a piece of paper behind a piece of glass

From this we see that there is a real end user benefit to tap into here. It turns out that there is existing infrastructure in Windows called “High DPI” which can be used to address this. High DPI is not a new feature for Windows 7, but it was not until Vista that the OS user-interface made significant investments in support for high DPI (beyond the infrastructure present earlier). To try this out in Vista, rt. Click desktop -> personalize and select “Adjust Font Size (DPI)” from the left hand column. 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.

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.

There are some mitigations that we can do in Windows, such as automatic scaling for applications which are not declared DPI aware (see Greg Schechter’s blog on the subject), but even these mitigations have problems. 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. For people who can’t read the small text without the scaling, this is a necessary feature to make the high DPI configuration useful. However, other customers may only be using applications that scale well at high DPI or may be less impacted by mismatched text sizes and may find the resulting blurry effect caused by automatic scaling to be a worse option. Without a way for the OS to detect whether an application is DPI aware on not, we have to pick a default option. It always comes back to the question of weighing the benefits and looking at the tradeoffs. In the long term, the solution is to make sure that applications know how to be resolution independent and are able to scale to fit the desired user preference, which requires support in both our tools and documentation. The challenge for a platform is to figure out how to get there over time and how to produce the best possible experience during the transition.

Short term vs. long term customer satisfaction

Using the model of high definition TV, we can see that in the long term it is desirable to have a high fidelity experience. The only problem is that even though the high DPI infrastructure has been around for several windows releases (in fact there is an MSDN article dated 2001 on making applications DPI aware), we were not sure how many applications are actually tested in these configurations. So we were faced with an un-quantified potential short term negative customer impact caused by enabling this feature more broadly. The first thing we did is to quantify the exposure. We did this by performing a test pass with over 1,000 applications in our app compat lab to see how they behave at high DPI settings. The results we found are shown below, which shows the distribution of issues for these 1000 applications.

One quick thing, when we say “bug” we mean any time software behaves in a manner inconsistent with expectations—so it can be anything from cosmetic to a crash. We categorize the severity of these bugs on a scale from 1 to 4, where Sev 1 is a really bad issue (such as a crash and/or loss of data or functionality) and Sev 4 is an issue which is quite subtle and/or very difficult to reproduce.

It turns out that most applications perform well at high DPI, and very few applications have major loss of functionality. Of course, it is not the ones that work well which we need to worry about. And if 1% of applications have major issues at high DPI, that could be a significant number. So we took a look at the bugs and put them into categories corresponding to the issue types found. Here is what we came up with:

Of 1000 applications tested for high DPI compatability, 1% had severity 1 issues, 1% severity 2, 5% serverity 3, and 2% severity 4, with 91% having no issue at all.

What we found was that one of the most significant issues was with clipped UI. Looking into this deeper, it became apparent that most of these cases were in configurations where the effective screen resolution would be quite low (800x600 or lower). Based on this, we were able to design the configuration UI in such a way that we minimized the number of cases where users would configure such a low effective resolution. One by one we looked at the categories of issues and when possible, we came up with mitigations for each bucket. Of course, the best mitigation is prevention and so High DPI is a major focus for our developer engagement stories for PDC, WinHEC, and other venues coming up.

Aggregate vs. individual user data

One thing for us to look at is how many users are taking advantage of high DPI today (Vista/XP). Based on the data we have, only a very small percentage of users are currently enabling the high DPI feature. This could easily be interpreted as a clear end user message that they don’t care about this feature or have a need for this feature. An alternate explanation could be that the lack of adoption is largely because XP and Vista had only limited shell support for high DPI, and the version of IE which shipped on those platforms had significant issues with displaying mismatched font sizes and poorly scaled web pages. Also, we do know anecdotally that there are users who love this feature and have used it even before Vista. Once again, we have to make an interpretation of the data and it is not always crystal clear.

Timing: is this the right feature for the market in this point in time?

Fortunately, we don’t have a “chicken and egg” problem. The hardware is already out in the field and in the market, so it is just a matter of the OS taking advantage of it. From a software perspective, most of the top software applications are DPI aware (including browsers with improved zooming, such as IE 8), but there remain a number of applications which may not behave well at high DPI. Another key piece of data is that display resolution for LCD panels is reaching the maximum at standard DPI. For these displays, there is no reason to go beyond 1900x1200 without OS support for high DPI because the text would be too small for anyone to read. Furthermore, this resolution is already capable of playing the highest fidelity video (1080p) as well as 2 megapixel photos. The combination of existing hardware in the field, future opportunity to unlock better experiences, and the fact that the hardware is now blocked on the OS and the software speak to this being the right timing.


Looking at customer data helps us identify ways to improve the Windows experience. In this case, we saw clearly that we had an opportunity to help users easily configure their display such that they would enjoy a high fidelity experience for media as well as crisp text rendered at an appropriate size. With that said, anytime we invest in a feature that can potentially impact the ecosystem of Windows applications we want to be careful about bringing forward your investments in software. We also want to make sure that we engage our community of ISVs early and deeply so they can take advantage of the platform work we have done to seamlessly deliver those benefits to their customers. In the meantime, the internal testing we did and the data that we gathered was critically important to helping us make informed decisions along the way. High DPI is a good example of the need for the whole ecosystem to participate in a solution and how we can use the customer data in the field, along with internal testing, to determine the issues people are seeing and to help us select the best course of action.




Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
  • [Microsoft] (Ryan Haveson)

    There have been several posts on app compat and high DPI (for example bluvg’s comment).  There have also been comments talking about the complexity and understandability of the High DPI configuration.  I thought I would send a quick note explaining some of this.

    In some cases the app compat issues can be mitigated by enabling or disabling the automatic scaling feature.  This can be changed globally by going to the DPI UI, clicking the button labeled “Custom DPI” and changing the checkbox labeled, “Use Windows XP style DPI scaling”.  When this checkbox is unchecked, applications which are not declared to be DPI aware are automatically scaled by DWM.  When it is checked, automatic scaling is disabled globally.  It is interesting to note that for DPI settings < 144 DPI, this box is checked by default, and for DPI settings >= 144 it is unchecked by default.  In some cases, changing the default settings can result in a better experience depending on the applications that you use and your DPI setting.

    It is also interesting to note that automatic scaling can be turned off on a per application basis using the Vista Program Compatibility Por.  Here is a link for more info on how to do that:

    Look at the section for “Disable Display Scaling on high DPI settings”.

    Also, ScottL, you should check out IE8 beta.  They have done a ton of work with the scaling feature and making layout work better when zoomed.

    --Ryan Haveson


  • 27 Oct first day of PDC 2008 due date for Beta1.. and 3 june 2009 date due for Final RTM...

    A less than yr is left for new OS...

  • One big problem is that you have to restart the computer to change DPI.

    And alot of programs looks just strange with high dpi-settings in windows.

  • Just like Chris O said. For people like me having 24inchs wide screen monitor who can't see tiny default fonts, there are many ways to approach this. But just like he said, none of them provide a desirable result.

    Just like he said, there are 55%, more than half of total users, experience the same as me. The only difference is that they choose to lower resolution and reading fuzzy fonts.

    And wait, I am not that 55%, I am using native resolution, but I am struggle with high DPI. Adding people like me, using high DPI as solution. There are probably more than 70% of people have issue with this tiny font standard.

    My question is, why tiny font standard? Why use an outdated standard that's designed for small screens? Yes, we have notebook, but many of them hook it to a monitor at work also. Why keep using a standard that is no longer appropriate for desktop users? It is like using DVD codec for HD Movies, that's just won't work.

    If standard font size is not tiny, we wouldn't have to use fuzzy resolution or high DPI anymore. High DPI particularly breaks: Live Messenger Wave 3, IE8 rendering on map direction. Anyway, I installed them since they are buggy with high DPI. But it is really annoying that I know my experience will always be ruined by high DPI bugs.

  • There is no point in wondering why people lower the resolution -- percentage of people with 20/20 vision is rapidly decreasing with age. Does your study take age and vision acuity into account? I am afraid not.

    Take 1920x1200 17" screen as an example -- it has 133 DPI while Windows default is 96 DPI. That means 38.5% smaller font if the DPI isn't adjusted properly.

    Now we come to the real issue. The size of Windows Shell Dlg font is not user adjustable -- even if the DPI is set correctly some parts of the UI stay small and unreadable.

  • Enough with the high-def content! You are giving it too much importance.

    I know it is the future that currently the adoption rate is very very low (look at the number of BD disks sold vs DVDs, be real!). Even more, the predictions are the switch to HD media will be slower than the switch from CD to DVD.

    So please, focus on the real issues of the users not on what you as a company and your corporate partners want to push.

    Work for your users not for the corporate media!

    The real issue is that changing DPI in Windows Server 2008 results in a lot of ugliness in the GUI; not all elements for all programs are scaled.

    When you choose to scale-up the GUI (via the DPI settings), a crying example is the window that appears when you do alt+tab: it is not big enough to accommodate the scaled-up icons.

    So leave the high-def content aside for a while and fix your core OS and components first.


  • I think You should consider also to introduce native 10bit color depth!

    Graphic cards have been 10bit color depth for a very long time! ATI since 19x0 series, nVidia since 2x0 series....

    Professionist who works with photo editing will appreciate that! And not only them....

  • Will Windows 7 support custom resolutions for us with screens that have broken/bad EDID information ?

    I am a unlucky owner of a ACER 37" LCD with bad EDID information, as it is now I can fool the screen to run 1080P without over/underscan only by setting the resolution to 1922 x 1080p under XP , but when I try with the same hardware (I tried both Nvidia and ATI) Vista refuse to allow a setting higher than the max resolution specifed by the EDID information so Im stuck with a 5% blackborder underscan. What is the mekanism that stops me from entering the resolution I want as it works in XP but not in Vista ?

    Maybe this is a question about drivers but both Nvida and ATI behaves in the same way .



  • I am stunned that Microsoft doesn't understand why most people with high resolution monitors turn down their resolutions!

    It is because that the text, menus and mouse functionality are unusable when the text point size drops below 10 points.

    The rules around human visual interaction with text have been around for almost 300 years and are a foundational part of all graphic designer's curriculum. Humans prefer 14 to 16 point text for reading body text but will accept 12 point text if it has a familiar form like serifs. You can use down to 10 point text if the content is engaging and the text follows a predictable form that does not require critical assessment of the form in order to perform uninterrupted reading.

    Human cognition of textual language communication falls in to two primary categories - letter by letter and word by word.

    The most natural, effective and fastest human cognition of text is word by word - where we recognize familiar words by their unique shapes and can anticipate what the next word will be by the context of their relative placement. This has been borne out for centuries through the use of serif fonts to accentuate the unique shapes of words and the use of capitalization to mark the beginning of sentences. This can also be seen when you recognize a familiar logo at a distance without thinking about each individual letter or when you can recognize a bus or trains indicia at a distance far greater than you can actually read its signage.

    When humans can't immediately decipher a textual communication by recognizing the word shape they fall back in to a letter by letter visual scanning and interpretation of each word. This form of textual cognition is 10 to 100 times slower than the word by word method and feels awkward and unnatural.

    When Windows XP/Vista is displayed on a high resolution display the text becomes too small to be recognized by the word by word method and the user reverts to the letter by letter method - all day long - every day. This is unacceptable to most users - especially to ones over 30.

    When my company's department got the first round of semi high resolution laptops they were not well received because the font size fell to 10 pts or less. The users did not accidentally discover bumping down the display resolution at all. They first went to the display control panel to increase the font size to larger and discovered that the GUI fell apart both on the desktop and especially in MS Office. Once one person figured out how to turn down the display resolution to fix the problem it spread like wildfire amongst everyone else because it was the only option available to return them to word by word cognition.

    Humans will not conform to new textual language cognition rules because high DPI resolution are available. The computer designers have to conform to the human textual language cognition rules.

    Use the high DPI resolutions to give us back serif fonts and a mechanism to adjust the text display to suit us - not the display engineers.

    I know that MS can't control how third party applications might handle variable font sizes - but by now Windows, Explorer and Office should be engineered to handle variable font sizes to best match the plethora of high - and low - DPI displays.  

    This ain't 1995 when display sizes and pitches were standardized. It's 2009 and the OS and the apps should work across super high resolution laptops and relatively low resolution HDTVs. Nowhere did this article mention how MS is going to support the now ubiquitous home HDTV with a VGA input.

  • If this is really going to work then there needs to be a better algorithm for scaling up small icons. The current one(s) result in either blurry, ugly icons (as in the case of the toolbars in applications with Office 2003-style UI) or blocky icons (as in the case of quite a lot of icons on the desktop and in the taskbar).

    Not to sound patronizing, but Apple has had this nailed since the first release of OS X. The solution: They have some magic algorithms that automatically, perfectly and completely fluidly interpolate every imaginable icon size, without requiring the app developer to provide vector icons. It's based on a series of icon sizes that are saved within each program's resources.

    So seeing what Apple is able to do, I firmly believe MS could be doing a better job. Most Windows applications do indeed provide a variety of icon sizes, so how about making Windows better able to interpolate between them, on an infinite sliding scale?

    (like Apple.) This may sound like a trivial issue, but I believe that the eyesore of ugly/garbled icons is one of the main reasons savvy PC users choose not to use high-DPI modes.

  • It's funny, but on my computer, DPI is refered as "% of normal scale" (of font scale) with the mention "normal scale is 96 pixels per inch". Then you can change the % (aka "scale" aka "DPI") and it will not only mention how many DPI it is, but also offer a preview of what the font will look like after the change.

    It's very user friendly and straightforward.

    The problem why normal users reduce resolution is, as I tried to explain above, because manufacturers build screens physicaly too small for a given resolution.

    Having general purpose monitors built with an optimal native DPI (such as in the table posted above by mariosalice) would already solve a bunch of problem.

    It would greatly reduce the number of users having to increase DPI or out of ignorance, lower the resolution therefore reducing the number of potential bugs.

    Now why Vista and/or some apps have issues while rescaling DPI is something I can't understand, but I hope my non-expert comment has been useful.

  • This can be changed globally by going to the DPI UI, clicking the button labeled “Custom DPI” and changing the checkbox labeled, “Use Windows XP style DPI scaling”.  When this checkbox is unchecked, applications which are not declared to be DPI aware are automatically scaled by DWM.  When it is checked, automatic scaling is disabled globally.

  • In Windows7, I find that setting high DPI on my machine makes the contents of app windows horribly blurry. For example, Chrome, or Visual Studio 2008. Presumably these apps are not 'DPI aware'

    Then, when I disable Aero, apps text shrinks down to ignore the high DPI setting and becomes sharp again.

    I'm surprised at the second problem, as it means the DPI setting is ignored by Windows. Seems like that kind of thing would be caught during testing?

    Some stuff that doesn't look blurry: the windows taskbar, window chrome, Firefox (apart from bitmap elements of the UI) Windows Explorer, MSN Messenger.

Page 5 of 5 (73 items) 12345