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 5 and 3 and type the answer here:
  • Post
  • "We don't have a way of knowing for sure why users adjust their screen resolution down"

    IN my house the reason why we actually adjusted down was reading the screen.  We could barely see so I backed down to 1280x720 and my wife down to 1024x768.  A very large part of the population is of the older range now.  They eyes are not so good anymore.

  • @PRab: See

    Icons are not the only problem, small details in custom controls can also be problematic. Text rendering is fortunately solved by OS.

  • I agree with donor.  Even if you can find it, not everyone knows what it does.  You usually have to find the explanation from a web PC Magazine or tip site. It's probably an important feature that Vista does not give full credit to - otherwise it would be upfront and explained in clear English.

    LCD - Vista - 1680x1050 - 32bit - native 22" have DPI set at 120 and 'Clear Type'. Every Vista animation turned on - what's the good of having it, if you don't use it! (Moving 28" for Windows 7)

    No problems .. No problems .. No problems ..

    (Except ati Catalyst Control Center does not list Res.. unless you set profile which sometimes it resets on boot to 1400x1050 - and as it does not have 1680x1050 is hard to reset as profile is ignored.) That's not MS problem.

    I tried dragging the percentage thing first and set at 110 - but needed 120.  Guess cause I'm 57 and 'baby-boomer. (There are more of us than any other group and we have the money to buy Windows! :-))  No research needed..

  • The Excell example given by kgeramidas is a perfect one: The goal of higher resolution is not (not only) playing HD-DVD: It's to see more things at once on the screen.

    It's not a Windows shortcoming. It's a manufacturer conception mistake: The higher the resolution, the larger the screen should be physicaly. The physical size in inches should be proportional to resolution in pixels.

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

    If not we are not out of the wood. Imagine that everytime an app starts Windows has to "think" whether it's  DPI aware?! Already the word "aware" is a severe misunderstanding of what a program is.

    I don't know how you are going to fix all the inevitable buggs coming out of that with the millions of softwares in circulation today. And finaly it will, again, hurt performance a la Aero and poeple will have to turn that off.

    Ok, it's very smart of you to think about it. But honestly hardware manufacturers should come up with practical devices. It's not the role of Microsft to fix, via software an ill-conceived hardware. And it's not the role of the main processor to correct the monitor display.

  • [Microsoft] (Ryan Haveson)

    It is great to see so much interest in high DPI and the material we posted here.

    There has been some discussion about IE and High DPI, so I thought I would send a link to an MSDN article about Internet Explorer 8 (beta) and High DPI. One of the things it talks about is the differences in DPI support from IE7 to IE8. Among other things, the IE8 UI is entirely DPI aware.

    Here is the link:  

    This article also has detailed instructions on how to set the DPI in Vista, since many people have commented that they thought a lot of folks don't know how to configure this setting.

    Enjoy and keep up the comments!

    --Ryan Haveson


  • I'm not convinced that Vista's DPI settings are inherently hard to get to.

    Right click on desktop -> personalize -> choose "adjust font size" from left hand menu.

    Maybe a better way of handling it would be to have it as a part of the whole "welcome" thing when a user first boots up Vista, or even a default wizard the first time an user logs on, explaining what DPI is, and how it will affect them.

  • Sorry if I am mistaken but isn't it more a problem of scaling than resolution? I mean, you can't really upscale  and expect a perfect result since the information that should go into those extra pixels isn't available, the best would be some sort of guessing, which is obviously far from perfect.

    There is already research about vectorial images (SVG as an example) that could be valuable as an alternative, that is, provided there is enough support and  resources available in order to persuade developers to migrate (and more importantly, publishers). Topic wise, at least some sort of vectorial text font control instead of per pixel (correct me if I am mistaken but I believe current font types rely on some sort of anti-aliasing and subpixel rendering). Well, I am aware of legacy concerns but it is not something that can't be sorted out, specially given current OCR technologies. Unfortunately for those images bound to cameras (in turn bound to the number of opto-electronic sensors [or their granularity]) there isn't much that can be made.

  • I appreciate the effort being made to improve the overall experience for the consumers. I believe the reason that people lower the resolution of their monitor is to make everything larger. The majority of the people don't know about the dpi setting. My grandma who's 86 is learning how to work computers. She goes to a class every week; she's always asking me questions that she has about the computer.  When I went over her house and went on her computer I noticed that her 22" monitor was set at a much lower resolution.

    She most likely doesn’t know that everything would be much clearer if it was set at the native resolution. But the negative would be that everything on screen would become smaller. In terms of scaling Windows Vista is better in this regard then windows XP but it's not perfect. If you set your computer at anything other than 120dpi or 144dpi then the OS looks awkward, some elements display correctly while others look distorted and some don’t scale at all.

    Most people want a perfectly scalable OS. Meaning everything will be the same size on a 19" LCD as a 24". Vista provided a good foundation for reaching that goal but Windows 7 should take it to the next step.  Websites are going to have to be high dpi as well because they'll keep getting smaller and smaller. Most websites are designed to look good at 1024x768. These days the majority of people are purchasing larger and larger LCD’s. I've got Windows Vista and a 24" monitor. I have it set at 120 dpi but I do wish that the scaling was better.

    Gadgets don’t scale at all which is a shame and some elements scale but become blurred. A prime example of this would be the Windows Photo gallery and the menu at the bottom of Windows Slideshow. At 144 dpi the start button becomes blurred, and the icons become spaced apart too much meaning I have to keep them smaller which I don’t prefer. For Windows 7 Resolution Independence should be Microsoft’s main focus.

    I know some people that were going to switch to Leopard because of the resolution independence feature that it was supposed to have. I feel that it's a more wanted feature then what's spoken about. 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.

    After that a popup could then have a little explanation about resolution and dpi with a link that would take you to an article on Microsoft’s website or a simple FAQ that’s on your pc. This would make people more aware and give them a better understanding about their display. In my opinion this would be the best solution.

    People won’t have to deal with everything being blurry and everything on screen would be nice and large meaning they would have less of a chance of eye strain. I feel that Vista should've had this feature but it's never too late to implement it.

  • I do support for a number of people, and I can honestly say that no matter how many times I explain the concept of physical resolution to them and give them the numbers they just don't get it.

    Inevitably, I get to a machine that is blurry as hell on an LCD (usually as a result of complains about just that as in "I thought it was supposed to be sharp and clear") - and inevitably they have forgotten it all over.  Reset and go.

    I have gotten to machines that were set wrong and when I mention it, I get told "I thought it looked funny", but again they had no idea why.

    So ya, software that changes resolutions and then do not switch it back correctly (a crash is often involved) combined with people who just don't get the technical details.

    I once met a person who thought that if you turned off the TV, the attached VCR would record a blank screen and flat out forbid turning off the TV while recording and forbad recording at night because it would "require the tv left on".  The person was so adamant, they would not even accept the truth or allow proof because it might screw up their recording.

    So expecting your average user to understand the technology is probably unrealistic and it should "just work" instead, or at least work hard to direct the back to the right settings.

    I had 1 case where a monitor was under-resed due to poor vision and it made the text bigger.  I never bothered showing them large fonts because they usually destroy interfaces.

    Oh, and I case where a user liked to run their tubes at 2 resolutions above what it was capable above because they thought it was somehow better that way.  You couldn't see or read ANYTHING.  When I moved that person to an LCD, I got calls because suddenly they could see distinct dots sharp and clear and wanted to know if that was normal.

  • I have to say that I agree most people don't know what DPI is, how to change it, or why they need to.

    I have noticed that the majority of users don't notice those links on the left side of dialogs like Personalize. They are looking in the center of the page for the link they are looking for.

    I have to admit that even I did not notice them at first. (And I consider myself very technically savvy. I am fluent in over a dozen programming languages and I am using a water cooled computer I built myself.)

  • I really appreciate the efforts Microsoft is making in this area--as an IT Director for a company with a large number of 50+ workers, these investments are very, very helpful.

    We spend quite a bit of time making sure our users are comfortable with the computers (and desks, chairs, etc.), and one of the reasons for moving to Vista was the much-improved high-DPI settings (as we also moved to new PCs and monitors).  Unfortunately, we also got bit by the compatibility issues.  One slipped through our app testing--our document management system software fully functions with the high DPI setting, but the icon representations it uses for files become blank (which is useful to the user--the icon shows the file type).  This happens sometimes happens for other reasons as well, so when we encountered this problem after rollout, we didn't suspect the high DPI setting initially.  A lot of time was spent figuring out the root cause.  Unfortunately, fixing this is not high on the ISV's list of development priorities.  I think for end users, it would be nice if there were a warning on this setting that it might cause compatibility issues (it might have had us test this particular scenario more thoroughly as well).  

    A more disappointing and disconcerting issue, though, is that as new apps are acquired/installed, the high DPI compatibility question must be asked again (and I think for most companies, these compatibility testing matrices are already mind-numbingly large, complex, and cumbersome).  The newly acquired apps may be apps with a long heritage and thus more likely suspect of incompatibility with the high DPI settings.  But... in our case, it was particularly disappointing to see an app that was built from the ground-up using .NET 2.0 have not only cosmetic issues in high DPI mode, but refuse to function at all.  Sadly, a relatively ancient application from the same ISV (I believe it's an old VB app) works in high DPI mode without an noticeable issues.  This one can't be blamed on our inadequate testing, as this app was released post-rollout.  So what can we do?  The .NET app is a replacement for an older application for a core business system.  We're more or less forced to turn the high DPI settings off.  Even if the ISV fixes that app (and it's likewise not a high priority bug for them), we may very well run into the same thing later.  Thus, given what I've seen personally, my hopes for a resolution-independent future are a bit dim.

  • One other thought--it would be nice to have a user control to scale certain DPI-unaware applications manually (perhaps a checkbox property on the EXE?).  For instance, some users have no trouble working at the standard DPI setting, but there may be one particular app that uses some ridiculously small (and hard-coded) font.  The DPI auto-scaling feature sounds great, but this only applies if you've changed the setting to a high DPI, correct?  Couldn't the auto-scaling ability be used for those occasional nasty apps even if the DPI setting was left at the default?

  • Surely the answer is to push for a vector based gui, where the icons and fonts scale properly?

    Windows has always had bad handling of resolutions, esp low ones.  Most of the system dialogs are non sizable with no scrolls.

    Anybody that's attached their pc to a crt tv will know the pain of not being able to see the apply button!

    I've seen that the latest visual studios are better designed in this respect, so obviously some one has thought about it!

    I'm not sure if the app dev's should be responsible at all. Scaling should be an OS task.

  • Very interresing article and comments !

    From my point of view and my experience users don't use their native resolution because :

    - they don't know what resolution is

    - they believe the size of the text/UI is dependant of the resolution so they change it

    - a program/driver changed it and never came back to native

    Users are unaware of the DPI notion so they don't set it.

    If they set it, do they know the "ideal" mix between resolution and DPI ?

    They perhaps have UI issues with DPI settings so they revert back default DPI.

    We need to uncorrelate resolution and size of UI/text/graphics.

    When you are seeing 15.4" screen in laptop having a resolution of 1980x1200, the same as we found in most 24" or 27" LCD there is obvious an issue.

    Some people will buy a 1980x1200 screen (whatever the size of the screen) to be able to have a large surface in their applications while some guys will buy a 27" screen to have bigger text.

    People should buy a screen only depending of the size of the monitor and the resolution used only as an indicator of the quality of the screen and its ability to display fine pixels.

    There from this, the user should be able to tune the size of the UI as he wants depending of his goals  (like we set the resolution): see big text, see large excel sheets etc.

    If I use the Excel sheet example of kgeramidas, he sees more cells with the default DPI settings than that the big DPI. This is normal. But  what is wrong is that he didn't buy a 1980x1200 screen to see all this range, he actually bought a 1980x1200 24" monitor to see this range AT THIS SIZE. He can see a larger range with a "lower DPI setting (if it was possible to set 75dpi)".

    That's why the user shouldn't have to set the resolution (or only in case of damaged resolution settings) but only have to set the "size of the text/UI". The resolution should always be at native resolution.

    For CRT monitors, there is often a trade off to make between the resolution and the refresh frequency (don't know how it is called in english)

    What do you think ?

  • The DPI issue is indeed a hard one to solve.

    The problem here is the never ending loop:

    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. Hopefully this will "force" the bigger ISV's (Intel, ATI, etc) to stop being a lazy bunch and actually fix their products.

    Secondly Windows itself must adjust perfectly do different DPI-s throughout.

    Third, force more people onto the WPF wagon and make better tools for creating vector graphics/icons. This step probably won't happen with Windows 7 or 8, but for Midori this is a must.

    Another thing I wonder is, couldn't some non DPI aware apps be scaled in such a way that every pixel is multiplied by 2 for instance:


    x => xx

    This probably won't make the app the exact same size as other DPI aware apps, but at least there shouldn't be any blur or other artifacts.

Page 2 of 5 (73 items) 12345