Follow-up on High DPI resolution

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.

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:

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.

true. let’s see into notebooks for example. Earlier it was possible to buy models with 0.29 mm pixel size, everything currently available has got 0.25 or smaller pixels (smaller pixels = bigger resolution on the same area). I know personally at least few people, who don’t want to change their old computers because of it… See netbooks – the same story (some users will buy it, but they will need bigger pixels).

> The hardware is already out in the field and in the market

…but you can work with computer manufacturers, show them the problem and even give some (small) discounts, when will produce hardware with smaller resolutions (I hope, that it will help them with making this :)). Believe me – it will give them and you profits.

I think that one, if not the main, reason why people do not modify DPI settings is because they do not know they can do it. I have three monitors at native resolution, 1920×1200, and scaling the DPI at 110 I have no problems reading text; this in spite of being fiftyone years old so my sight is not as sharp as before. What I think would really be hlepful is both to make people aware of the ability to scale DPI and to educate the average Joe user about what DPI are, why modifying the settings is useful etc.

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

It seems you guys are having issues getting all devs to work on this problem, much like the LUA problems that have plagued Windows. So is this change going to be like the LUA fix?

If so, how do you plan on forcing the issue on devs?

For those of you out there who are unaware, LUA stands for Least User Access, and is the principle of not giving applications rights unless then absolutely need them to run. It is one of the best things to have shoved to the forefront (and MS did), and a great tool in administration of any computer. (Note the lack of calling it by the feature name in Windows so that readers may have an unbiased opinion about it.)

I’m aware of it, but it defeats the purpose of having a high resolution monitor.

I have a 28” lcd and 2 24” lcds, all have a native resolution of 1920×1200 all spanning 1 desktop. I got them on purpose, to be able to see as much as possible.

I’ll use excel for this example and I’ll use a 24” since it’s more common than a 28”. At the native resolution and @ 96dpi, i can see the range A1:AC61. at 120dpi.all I can see is A1:W46. I’d have to set the resolution to 1440×900 @ 96 dpi to see the range A1:W46.

So, why would I spend a premium on getting 1200 lines of resolution to only use the equivalent of a much cheaper 900 lines of resolution lcd?

Doesn’t make any sense. If someone can’t see that well, they shouldn’t be buying a 1920×1200 resolution monitor because it’s a waste of money. Go with a lower resolution monitor.

For me personally, I like the ability to customize the DPI to look the way I want, but in the process there is some trade offs. I remember when I received a laptop with Vista that has a resolution of 1680 by 1050, the text was so small it started hurting my eyes. I went to the Adjust Font size (DPI) link under Personalize and increased the text size, but I notice it affected a few things, like taskbar button icons becoming bigger, system tray icons got bigger and jaggy. Certain graphics too for instance such as the Windows About dialog logo became jaggy. My DPI size is now at 120.

Having better DPI compatibility will be great, but by far the number one concern for the UI of Windows 7 that I have is customization. Windows has a very long way to go to make itself more customizable for the user.

Also, when I first heard of the WPF and Aero I thought there would be better implementations out of the box. I really thought that a new 3D UI was going to be what made Windows Vista. While the interface is a lot better than XP, I had something in mind that was more like what is available now in Compiz-Fusion for Linux. The Windows 7 UI needs to take better advantage of WPF and 3D graphics than Vista did.

Also, users who are experiencing effects with icons on the taskbar and system tray, you can adjust their size by adjusting the size of windows active title bars in the classic appearance properties.

Come on, the real reason why people set lower resolution instead of increasing DPI is because they just don’t know about this option!

Adjusting screen resolution is available in screen properties, while adjusting DPI is hidden in the tabs behind the "advanced" button. So clearly, most people will try adjusting resolution first. And many of those who makes it to the DPI adjustment tab, will leave, because it requires a lot of thinking to understand what DPI adjustment is about.

My advice is:

Move DPI adjustment to screen properties, and add a graphical explanation of what it does

As an occasional developer, why is it my problem what DPI a client is using. Let me make buttons 15% the height of the window or a text box that is always centered. Taken to the extreme, your computer would look the exact same no mater what resolution you are at (except more blurry at low resolutions).

"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 1280×720 and my wife down to 1024×768. A very large part of the population is of the older range now. They eyes are not so good anymore.

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 – 1680×1050 – 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 1400×1050 – and as it does not have 1680×1050 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.

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.

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 1024×768. 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?

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 1980×1200, the same as we found in most 24" or 27" LCD there is obvious an issue.

Some people will buy a 1980×1200 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 1980×1200 screen to see all this range, he actually bought a 1980×1200 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)

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:

xx

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.

This is pretty simple folks. For way too long, users have been forced to think of computers in terms of resolution e.g. 1280×1024. Most graphics are done as fixed size bitmaps e.g. 16×16 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 1280×1024. 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 8×4.6cm at 400DPI capable to show 1280×720 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.

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.

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.

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 1600×1200@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)

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" 1920×1200 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.

"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?

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)

… (in fact right now I am running at high DPI on a 24" 1920×1200 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.

steven_sinofsky

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

I have a 1920×1200 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 1280×720 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 1280×720 at 120DPI but the operating system reports to this particular program a resolution of 1920×1080.

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 (1920×1600) 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 1024×768 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?

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" 1440×900), 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 1680×1050 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.

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.

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?

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.

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.

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:

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 1920×1200 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.

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.