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.

Conclusion

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.

 

 

--Ryan

Leave a Comment
  • Please add 7 and 6 and type the answer here:
  • Post
  • My laptop is 1920x1200. When I first installed Vista, I tried changing the DPI to 110 from 96.  Everything looked terrible so I changed it back!

    Most browsers have a zoom function (the newer browsers handle this very well) so I think it's not a problem for the web, only desktop applications.

    We need to move to vector graphics ASAP! Why the Vista desktop wasn't built from the ground up using WPF/Milcore is beyond me - you have the technology already!

    Are you going to do this for Windows 7?

  • It is worth taking a look at the post referenced by @mogi ... it demonstrates why vector-based graphics do not inherently solve the technical challenge of needing a scalable UI.

    See for example http://www.firewheeldesign.com/sparkplug/2006/April/icon_design_bitmap_vs_vector.php

    --Steven

  • This is pretty simple folks. For way too long, users have been forced to think of computers in terms of resolution e.g. 1280x1024. Most graphics are done as fixed size bitmaps e.g. 16x16 by developers. Therein lies the problem. In fact, what most users need to see is something of a given size. An inch is an inch. DPI is a way to convert what is the size of a pixel into a number of inches. Do people really need to know what the DPI is? Just display what they want to see to them, and let them choose the size (i.e. inches) they want. They don't need to know they're running 120 DPI, or that their screen is 1280x1024. It should be immediately apparent what DPI a monitor is based on the number of pixels and the diagnonal screen size/vertical and horizontal sizes; in effect a monitor has a FIXED DPI in native mode. And furthermore, the point size of text is also predefined and FIXED: there are 72 points to an inch. Thus, if people want larger text, they simply change the font size (point size) and all UI elements should scale with this. We should NOT have to fart about with this resolution and DPI stuff. If monitors have different DPI in vertical and horizontal, then the dispplay drivers should know this and either apply auto-scaling or tell the user to pick which dimension gets squashed, and I'll bet the deciding factor is text height not width. Oh and BTW, we'll pretty soon be int he situation where no screen element is fixed (i.e. a fixed bitmpap or image), but rather should be drawn directly (vector, video) and is highly likely to be dynamic. This is a kludge right now in the OS since these should be scaled to size (i.e. inches), not a fixed size. And in fact, I'll also bet developers will want to vary the size (its say 1/4 inch across unless something happens, then it expands to 1/2 inch and pulsates to attract attention).

  • Did I get it right? Are you about to give Seven the ability to recognize the screen DPI and resolution and choose the right settings?

    This is great news.

    Future proof. Small screens 8x4.6cm at 400DPI capable to show 1280x720 high def TV.

    This is a list the right pitch width and height according to the DPI capabilities at each resolution. In any case the right size to get readable letters is a job Microsoft can do for us. Anyway, with Vista, ctrl-scroll resizes almost everything. Great, thank you.

    Hpix Vpix DPI pitch Width Height

    1280 0720 0096 0,265 338,67 190,50

    1920 1080 0096 0,265 508,00 285,75

    1920 1200 0096 0,265 508,00 317,50

    1280 0720 0120 0,212 270,93 152,40

    1920 1080 0120 0,212 406,40 228,60

    1920 1200 0120 0,212 406,40 254,00

    1280 0720 0170 0,149 191,25 107,58

    1920 1080 0170 0,149 286,87 161,36

    1920 1200 0170 0,149 286,87 179,29

    1280 0720 0400 0,064 081,28 045,72

    1920 1080 0400 0,064 121,92 068,58

    1920 1200 0400 0,064 121,92 076,20

  • 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. Developers already have too many things to worry about. Making their life simpler will result in more reliable and consistent user experience.

  • @AndrewWen -- Mac developers face the same situation. Both Microsoft and Apple provide development libraries that app developers can use that help to make sure the UI scales appropriately -- see for example http://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/.  This is similar to the article that Ryan pointed you to on MSDN.

    As Ryan said, this is about the assumptions software makes relative to the hardware that already exists.

    --Steven

  • To say that you can't create vector based icons because the border lines will have different widths at different scales is misleading.  You don't have to specify that all line widths are a constant.  If it's another excuses for not creating the windows UI in WPF/XAML, it's a sad one and borderline lie.  I can see it's more about "camps" than it is about whats best.  If you come from the old school and you're stuck there, you're going to look for any flaw and reasoning you can to defend your position, no matter how irrational.

    The windows UI needs to be unified and the only way to do it is to touch every part of the UI and update it to WPF based UI forms.  From there, you can add your updated elements.  As it stands today, you can't even develop Windows Sidebar gadgets in WPF (that's weird but proof that it's not just about technology).

    I am doubtful that we'll ever see it happen, due to politics and the current paradox at MS.

  • Will Windows Presentation Foundation solve this problem of incompatible apps? When will developers get all the controls they get with Winforms on WPF?? There is no buit in way to use many of the vista specific UI elements in .NET 3.5 , but thats another topic.

  • @Steven

    > As Ryan said, this is about the assumptions

    > software makes relative to the hardware that

    > already exists.

    what about making changes in giving "designed for..." ? for example: it will be given to these series of notebooks, where is available at least one model with big pixels (low native resolution) or where are used such resolutions, which will allow for making good scaling (equal to low resolutions)...

  • burgesjl wrote that non-advanced users don't have to know terms such as "DPI", "resolution" etc and I agree.

    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.

  • "Is trying to get developers to make resolution independent programs really hard? "

    With the Win32 API and GDI and all that jazz?  You bet.

    No one, not even Microsoft's own products, give a damn about UI on Windows. The APIs aren't designed to make it easy to create well-behaved, nice-looking interfaces, most of Microsoft's own products break about 80% of the company's user interface guidelines, said guidelines are pretty much invisible to anyone interested in following them, and third-party applications have always attempted to look nice by themselves, not to play nice with the OS, at difference screen sizes, resolutions or anything else.

    That's just how it is. As much as the 7 team may want to improve DPI independence, they're still up against a 25 year old ingrained culture in the entire Windows ecosystem, of "doing our own thing". They might provide new and better API's to aid in this, but Visual Studio or MS Office wouldn't *dream* of using the UI API's provided by the OS. They build their own. Most of the software bundled with the OS (Notepad and such) is far too simple to support anything fancy like that. Windows Media Player or Messenger try to look more like pieces of art than anything representative of "what Windows software should look like".

    And third-party software isn't any better, of course. If the platform doesn't already have a consistent look, why should third-party software bother trying to blend in? If we're still wallowing in non-DPI independent software, where's the encouragement for making my product DPI independent?

    If some developer somewhere decided that he actually wanted to write software that followed all the platform's UI guidelines, was DPI independent and well-behaved.... he'd be on his own. There might be a few code snippets on MSDN, but that's all. There certainly wouldn't be much existing software to imitate.

    And he'd still have to wrestle the 20 year old API's (which are certainly not designed to make DPI independence the default, or simple to achieve) into submission.

    Anyway, just thought I'd suggest a possible reason why so many people run at non-maxed resolution. I'm not running at my monitor's max resolution, because it's a CRT, and I don't want to be stuck at 60hz refresh rate.

    I'd much rather have 1600x1200@100hz than 2k-something x whatever @ 60 hz.

    I don't know if this is already taken into account, or for that matter, how many people still have CRT monitors, but I think it's pretty common for CRT users to not use the absolutely highest resolution supported. And no amount of DPI independent software can change that.

    And as said above, another obvious reason why people lower their resolution is that this is straightforward to do, and most (or lots of, anyway) people are familiar with it. If everything is looking itty bitty, you lower the resolution.

    Where do I go if I want to change the DPI setting instead? Is it as straightforward to find and change as the resolution settings? If so, that's not good enough. It has to be far far easier. If it's hidden away in a control panel somewhere, users won't see it. They'll follow the force of habit (I can't read the text -> I'll lower the resolution)

  • @Jalf -- some harsh words for an entire ecosystem :-)

    The main thing to consider is that the problems we are talking about here are not debilitating.  Apps still run and as Ryan showed, we're at the 99% level of success.

    The challenge is that no one could really have planned for this change.  One could even look at it through the lens of other shifts that no one planned on such as moving from a segmented memory model to a flat address space.  It required lots of changes, even when the segmented programs continued to run (just compile in LARGE mode).  But even then code that assumed word size needed to be looked at.

    This is also similar to changes like ANSI to UNICODE, or perhaps what most applications run into when they first try to work in "foreign" scripts.  

    In all these cases the tools and frameworks do offer the mainstream developer the mechanisms to make this work.  And in all cases, that is necessary but not sufficient.  There are some basic practices that need to be followed.  That doesn't make the developers or their code less excellent--it is a new technology and a new paradigm.  See for example http://msdn.microsoft.com/en-us/library/ms969894.aspx.

    There are two main classes of problems.  One that is "relatively" benign is layout of UI, particularly static text that no longer fits.  This is just a matter of handling the layout. Obviously this involves all sorts of text based UI elements.  (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.

    The second has to do with bitmaps in the UI.  Many folks have commented on how if bitmaps were replaced with a vector format this would be a solution.  It isn't quite so simple as there is a reason there are both bitmap and vector formats.  Many UI elements are more usable as "photos" and photos are not well represented as vectors.  And the issue of scaling and proportions does matter, at least to some.  That is not to say one could take vector graphics far or design a different UI paradigm where vectors are the dominant element.  But the "world is a bitmap" (that is a photo), and so many prefer the user interface to follow.  But for this it turns out that a couple of resolutions and knowledge of the hardware ecosystem (and physical realities) and all but arbitrary cases can be covered.  

    I think we're in a good spot here and Ryan's post showed that we're prepared and understand the challenges.  We are working to continue to improve the tools and information so we can all continue to make this transition together.

    You are correct, that not every bit of software from Microsoft is perfect either.  Office had lots of graphical elements that scaled poorly and lots of layout that did not handle large fonts correctly.  It was something that was part of the ribbon design from the start.

    The discussion, even when it is a bit of a debate, is great.  While I can only speak for myself, it is clear there is good learning going on about what are important issues and where sensitivities are regarding those issues.

    --Steven

  • Yert wrote:

    "Is trying to get developers to make resolution independent programs really hard?"

    Absolutely.  Microsoft is trying very hard to get developers to use adopt WPF and Silverlight, which will help substantially to be honest.  If you use Win32/GDI, then you, as the developer, have to do everything if you want your app to support resolution independence:  picking the correct font size, scaling any images, and ensuring correct position of all UI items (among others), for the current screen resolution.  Here's a little clue, developers usually don't bother with this, it's something that tends to fall off the feature list for one reason or another when working on a project.  Though sometimes, you might include some UI to allow the user to pick a larger font as necessary, hardly a comprehensive solution however.

    About DPI:  some Windows components/UI and some applications simply do not render well at anything other than 96 DPI.  If you try any other value, then you will get display weirdness.  Even if the developer is kind enough to make the application resolution-aware, the system's DPI setting is usually overlooked.  I believe the metrics regarding high DPI bugs are way too low, the percentage should be quite a bit higher.  You may want to verify your numbers again.  This is a rather tricky thing to test for (of course), you probably need the human tester to try out all 1000 apps, then all screens in each app, at > 96 DPI, some screens are tolerable, some are flat out broken.  Maybe it would make more sense for users to post screen captures of DPI bugs online somewhere, these would be quite interesting.

    This particular blog topic, Follow-up on High DPI resolution, is a quite an excellent topic.  I feel that the 55% number about users decreasing their resolution makes sense and I believe that this is a rather important number at that.  55% is a large number, would you call these folks visually impaired?  Perhaps us visually impaired folks are no longer a very small minority.

    With regards to making your screen easier to read, you have four options, none of which are comprehensive:

    1)  An application utilizes WPF/Silverlight, or does it the hard way, to support resolution independence.  As time goes on, more applications might actually do this.

    2)  Change the system's DPI.  I don't feel this is even an option, causes a lot more problems than it solves.

    3)  Change Windows' system fonts.  This can help with the display of some fonts that applications use.

    4)  Use some sort of screen magnifier, there are plenty of these critters on the web, and Microsoft has two (one that comes with the OS, and one as part of Intellipoint software for MS mice, which is quite nice actually).  This option is half-decent, but most users may not be aware of such possibilities, even if they do figure out how to reduce their resolution.

    Here's another clue, reducing your resolution will in fact give you fuzzy text on an LCD, but this is much preferred to "sharp" text you can't even read at the screen's native resolution.

    Great topic/discussions, this topic is actually two gnarly problems to solve:  how do you get new applications to work properly for various DPI/resolutions and how do you get old applications to work properly in the brave new world?

    -So long and thanks for all the blogs

  • which uses technology in Seadragon?

    http://www.youtube.com/watch?v=PKwTurQgiak

  • changing the DPI (at least in windows xp) is only possible as a global setting. That means, if you have a high resolution 15inch laptops and a big 24inch monitor with the same resolution either one of them looks blurry/bad or isn't readable.

    We have this problem, cause we're using our laptops together with a docking station and the laptop bescomes the second monitor.

    By the way, vector graphics is the only way to have good looking icons, no matter what the resolution (and dpi) is. So windows 7 should support both worlds vector graphics and the old icons if it wants to be a cool thing (IMHO)

Page 3 of 5 (73 items) 12345