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 6 and 1 and type the answer here:
  • Post
  • ... (in fact right now I am running at high DPI on a 24" 1920x1200 60hz and noticed that the text does not fit in the dialogs of a very popular media player).  The fonts, being truetype "vectors" look great but there just isn't enough room for them.


    With Vista I had to load the aero theme once again after I changed the DPI, to make things better.

    I have a 1920x1200 96DPI LCD monitor and it looks better at 96DPI.

    Though a 120DPI LCD monitor looks much better at 120DPI. In this case I might have problems with some applications (there is a 10% probability, as we saw here).

    Lets see this "not enough room" problem with an example.

    A program looks OK at 1280x720 at 96DPI on a CRT screen (DPI independent) or an LCD 96DPI screen.

    In case there is a box that needs the hole horizontal screen it should be 338.67mm wide.

    1280 0720 0096 0,265 338,67 190,50 (from a previous post)

    Now we change the screen to use a 120DPI LCD and set the OS DPI at 120. The same box is now 270.93mm wide.

    1280 0720 0120 0,212 270,93 152,40 (from a previous post)

    Apparently We cannot fit the same text in this smaller box.

    We might use smaller or narrow fonts, but We should be able to use the same fonts at the same readable size.

    What could we possibly do?

    Lets change the resolution the operating system reports to this program, without a real change in resolution.

    Suppose the original resolution is 1280x720 at 120DPI but the operating system reports to this particular program a resolution of 1920x1080.

    At 120DPI the size of the box becomes 406.4mm.

    1920 1080 0120 0,212 406,40 228,60 (from a previous post)

    Now there is plenty of room for this application.

    Actually we might also find a better resolution that fits.

    This was just an example about the problems we have with some applications when we uce high DPI monitors.

    With old CRT screens there was no problem. We could easily drop down the DPI.

    With LCD screns though we cannnot change the DPI without glitches. It is fixed and the monitor looks great at it's own DPI setting.

    Something has to be done for future applications to scale well, with different monitors, that have different DPI and size, without braking old applications.

  • Agree with the comments from AndiG.  I would use the High DPI setting if it didn't require a restart, in no small part because I switch from laptop screen (1920x1600) to projector or docking station frequently.

    Additionally, many dialog boxes are completely unreadable when you turn this on.

    I'd venture to say that 90% of the time that I lower my resolution is when I'm web browsing and doing a lot of reading.  I have to do this because the Zoom feature of IE screws up page layouts.  If the IE team would fix this bug, I'd probably never lower my resolution or need a higher system-wide DPI.

  • I only have one thing to say: If a user cannot find it, it doesn't exist or you didn't develop it.  That is to say, the issue is not with setting or not setting the default to High DPI resolution but the issue is with user experience. Its not easy and intuitive for common users to do this.

  • I currently use 1024x768 with an Acer 22" monitor and a Sony 40" TV.  By using this....I do not have to readjust settings for each use, and have a very good picture on the dual outputs of my HP Media Center.

  • I have a 15" laptop with a native resolution of 1920*1200. So I tried high DPI when I installed Vista on it. It worked pretty well, but these days I have High DPI disabled. Why?

    Because the DPI rate is configured overall, not per output device. Sometimes I use my laptop screen. Sometimes I use my home or work monitors, sometimes I project with 1024*768 resolution. High DPI settings do not work on anything but my laptop screen.

    So: The DPI setting should be determined by the currently used monitor. Because that monitor has a certain DPI rate. When I plug in a different monitor, the DPI rate should adjust accordingly.

    Here is the UI I imagine:

    When I attach a monitor, Windows asks me what the physical size of the monitor is (best be able to specify both diagonale and width/height). Then give me the choice whether I want to see windows with small text, medium text or big text. And then please maintain the resulting DPI ration for that monitor whatever I do (especially when I switch resolution like in the projector case)

    And BTW, while we're at it: There is another area where Windows should have per-device-settings, not per application: Keyboard layout. Currently, I can set keyboard layout globally or (with the language toolbar) per application. However, my keyboard doesn't change layout per application. My keyboard may change layout when I plug in a different keyboard. So why not have per-device keyboard layout?



  • After thinking over lunch:

    In essence, there are only three factors that should be relevant to size of anything on screen:

    1. How big is the screen (physically!)

    2. How far from the eyes is the screen?

    3. User preferences (maybe a slider or something to set this)

    These parameters should be maintained on a per-device-base and would make on-screen rendering great, no matter if I'm using a laptop display or an LCD TV



  • Lots of good discussion on this topic!

    I'd like to add that there is one other factor that needs to be considered beyond resolution and DPI, and that is viewing distance.

    For example, my smartphone has a 120dpi display.  However, the viewing distance to the screen is very small, so you don't need to use 120dpi fonts, in fact, you probably want small enough fonts so you can fit lots of text on your small screen on the phone.

    My laptop also has a 120dpi display (14" 1440x900), and 120dpi fonts look great on there.  But, being a laptop, the screen is so close to the keyboard, you are pretty close to the screen all the time.  So the 96dpi fonts look fine too.  They are unreadable to anyone standing away from the screen, of course, but nice when you are right up in front of your laptop typing.

    At home, I have a computer hooked up to a 42" 1080p HDTV.  It is no doubt an HD screen, yet very low dpi, in fact, around 75dpi.  In that case, since I can be pretty far from the screen in my family room, larger font sizes, like the 120dpi fonts, would be great in that situation.  

    In fact, what kind of fonts does Media Center use?  Nice and large fonts.  What fonts are you supposed to use in PowerPoint presentatations?  Large fonts.  In both these cases, the distance of the viewer is what determines readability, not resolution or dpi.

    So I'm just putting this idea out there about viewing distance being important too.  Not really a Windows 7 problem, but just an observation about font size, dpi, and readability.

  • I don't have time to read all the comments, unfortunately, but I agree with the second poster -- I would guess that most people just don't know how to use such an option.

    Also, I'd like to chime in with a Wag of the Finger at the Display Industry: WHEN DID 1680x1050 EVER MAKE SENSE? 16.8:10.5 aspect ratio? seriously? C'mon knuckleheads, make LCDs the same size as HDTVs and lower EVERYONE'S overhead! Also, make them higher resolution than 1080, since people will obviously want that.

  • - Why should I reboot when I change them? (plus it's not needed, loging out works as well)

    - Why can't I set a diffferent DPI settings on each screen? if I keep the normal DPI my external monitor is OK, if I set a readable DPI on my laptop my second screen is too big.

    - Even VS2008 doesn't support 120DPI. After reading this blog I gave it a try, and now the context menus are way out, when I mouse click.

  • I've used or tried to use this feature in Vista and XP (at least).  I currently use the 120 setting in Vista.  I'd use a higher setting, but the fact is that

    a) when the text is the right size, everything else looks terrible

    b) some applications are seriously messed up.  I recall one (Norton AV?) where the main dialog box was a fixed size, meaning that half the control options were invisible or inaccessible.

    In short, it's a good concept, but doesn't work very well to date.  I'd like to use the highest resolution I can, but only if it's legible.  Thankfully, Firefox and MS Office handle scaling pretty well, so the Web and my key documents at least are legible.

  • Hi,

    Sorry I have not had time to read through all comments. One of the reasons I believe that many users are running 1024*768 would be they just don't know any better - I mean maybe it's not just a case of setting their resolution down but just keeping it @ default? Even in this day and age how many computer users are literate beyond the point of opening up Office apps and IE?

  • @ jrronimo

    I believe the reason that 16:10 (as per your example) monitors are the norm, rather than 16:9 (as found in widescreen televisions) is because of the severe loss of screen real-estate when using a 16:9 standard.

    For example, on a display of a given diagonal size:

    a 16:9 display would have 12.3% smaller screen than a 4:3 display.

    a 16:10 display would have 6.8% smaller screen area than a 4:3 display.

  • Some years ago, when content got to small, we moved from 13" to 15" and up the pixels, then to 17"..... And we reach a practical limit in laptop size.

    Just wondering what influence will pocket size projectors have in future? Will it replace build in screen with some large expandable projector surface if manufacturers can achieve high resolution and brightness?

    It have the potential to bypass the readability problem to some extend as we did with screen size previously. Until the projector surface get ridiculously large. Hopefully by then all applications are DPI aware.

  • Indeed, vectors alone will not be able to solve it, most notably due to the fact that real images raw format is bit mapped.

    Let us not oversimplify the issue, also, what is the real problem? Following the example at: ""

    where the main concern is aspect ratio and thickness of vector lines, one could argue that it is better to have one sample from each ratio than for each size and that the vector specification could be improved in order to contain information concerning the thickness. Also it is not as if the vector draw return can't be filtered.

    That is all nice, but not the point. Monitors will continue improving and new standards will surface sooner or latter like the new UHD from NHK. Also smaller DPI at LCD screens is always better, except for scaling concerns as mentioned, then again it is not really those small pixels fault.

    What I believe to be the main cause of concern is awareness and its limitations, there is not flexibility enough at runtime to handle everything, especially those unpredictable new standards, I mean, one can't be aware of something he don't know exist or even doesn't exist yet. You would need all sorts of OS tricks to try and cover all holes, while new holes would continue to surface. Moreover, that also imposes limits to legacy support. Such problem cannot be solved even by brute force like locking the windows resizing to aspect ratio (filling with black stripes at full screen). My guess is some sort of recompiling or even a paradigm shift of distributing intermediate code (not source code obviously) which has its compilation finished at install time instead of current packed machine code. That would in turn also be problematic as the correct libraries and compilers would need to be present, not to mention compatibility and the time it would take to do so at less capable machines or for more complex programs (you can get the feeling of it from the gentoo project), though being intermediate code helps.

  • The number of 1600x1200 monitors is going down since they are not wide-screen format.

    Also 1920x1050 is used on TV sets, almost all monitors of this size use 1920x1200.

    Its also likely that the 1280x1024 monitors are either CRTs or older 17" or 19" non wide-screen LCDs.

Page 4 of 5 (73 items) 12345