Engineering Windows 7

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

More Follow up to discussion about High DPI

More Follow up to discussion about High DPI

  • Comments 48

 

Excellent!  What a fun discussion we’ve been having on High DPI.  It has been so enriching that Ryan wrote up a summary of even more of the discussion.  Thanks so much!  --Steven

There have been quite a few comments posted regarding high DPI, along with some lively discussion. Most of what has been said has been good anecdotal examples which are consistent with the data we have collected. For the areas where we didn’t have data, the comments have helped to validate many of our assumptions for this group. It is also clear that there are some areas of this feature which are confusing, and in some cases there is a bit of “myth” around what is ideal, what is possible, and what is there. This follow up post is mostly to summarize what we have heard, and to provide some details around the areas where there has been a bit of confusion.

Here is a list of our top “assumptions” which have been echoed by the comments posted:

  • Most people adjust the screen resolution either to get larger text, or because it was an accident
  • There is a core of people who know about high DPI and who use it
  • Some people prefer more screen real-estate while others people prefer larger UI
  • Discoverability of the DPI configuration is a concern for some
  • App compat is a common issue, even a “deal breaker” in some cases
  • IE Scaling is one of the top issues listed (see IE8 which fixes many of these!)
  • Lots of complexities/subtleties and it is pretty hard to explain this feature to most people

There have also been a number of areas where there has been a bit of confusion:

  • Is it true that if everything were vector-based, these problems would all go away?
  • Shouldn’t this just work without developers having to do anything?
  • How is this different from per-application scaling like IE zooming?
  • Should DPI be for calibration or for scaling?

Most of these topics have been covered to some degree in the comments, but since there has been so much interest, we decided to go into a bit more details around a few of the top issues/concerns.

Vector Graphics vs. Raster Graphics

With PCs, there is always the hope of a “silver bullet” technology which solves all problems making life easy for users, developers, and designers across the board. As an example, some of the comments to the original posting suggested that if we just made the OS fully vector based, these scaling problems would go away. It turns out that there are several issues with using vector graphics which are worth explaining.

The first issue is that oftentimes when an icon gets to be small in size, it is better to use an alternate representation so that the meaning is clearer. Notice the icons below. In this case, the designer has chosen a non-perspective view for the icon when it is rendered at it’s smallest size.

Example of the same icon treated differently depending on size.

This is because the designer felt that the information expressed by the icon was clearer with a straight-on view at the smallest size. Here is another example illustrating this point:

Additional example of icons treated differently as the size changes.

Of course, this means that the designer must create multiple versions of the source image design, so there is additional complexity. The point here is that there is a tradeoff that must be made and the tradeoff is not always clear.

Even when one vector source is used, it is common to have size-dependent tweaking to make sure that the result is true to what the designer had in mind. Imagine a vector graphic which has a 1-pixel line at 128x128 that gets scaled down by 1/2 to 64x64. The display has no way of rendering a perfect 1/2 pixel line! In many cases the answer is that the renderer will “round” to a nearby pixel line. However, doing this inherently changes the layout of the sub-elements of the image. And there is the question of, “which pixel line to round to?” If the designer does not hand tune the source material, it will be up to the rendering engine to make this decision, and that can result in undesirable effects. One could say that this should therefore define rules about what elements should be use in a vector, but that only further restricts what concepts can be represented.

It turns out that even the TrueType fonts which we use in Windows are hand-tuned with size-dependant information in order to make the result as high quality as possible. Most of the TrueType rendering pipeline is based on algorithmic scaling of a vector source, but there are size-dependent, hand-coded “hints” in TrueType which the designer specifies to direct the system how to handle edge cases, such as lines falling between pixel boundaries. Here is a link describing this in more detail: http://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx

It is not even true that vector graphics are necessarily smaller in size (especially for small images). Most designers create graphics using an editor which builds up an image using many layers of drawings and effects. With bitmap based graphics, designers will “flatten” the layers before adding it to a piece of software. Most designers today pay little attention to the size of the layers because the flattening process essentially converts it to a fixed size based on the image resolution. With vector graphics, there is no such flattening technique so designers need to carefully consider the tools that they use and the effects that they add to make sure that their icon is not extremely large. I spent some time with one of our designers who had a vector graphic source for one of our bitmaps in Windows and the file was 622k! Of course that file size is fixed regardless of the resulting resolution, but that huge file flattens into this 23k PNG bitmap.

Of course, a hand-tuned vector based representation of this could be probably made smaller if the size constraints were part of the design time process. But that would be an additional constraint put on the designer, and one which they would need to learn how to do well.

How do we help developers?

For applications that need to carefully control the layout and graphics, or scale the fidelity of the images based on the available resolution, having a way of specifying specific pixel locations for items is important to get the best result. This is as true on the Mac as it is on the PC (see http://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/). There is often a belief that if we just provided the right tools or the right framework then all these problems would go away. We all know that each set of tools and each framework have their own set of tradeoffs (whether that is Win 32, .net, or HTML). While there is no silver bullet, there are things we can do to make writing DPI aware applications easier for developers. As an example, there are two important upcoming ecosystem events in which we will be talking in detail about High DPI. We will also have materials which we will be making available to developers which will help educate them on how to convert existing applications to be DPI aware. The first event is Microsoft Professional Developer Conference, where we will talk about High DPI as part of the talk “Writing your Application to Shine on Modern Graphics Hardware (link)”. The second is the Windows Hardware Engineering Conference, in which we will be discussing high DPI as part of the “High Fidelity Graphics and Media” track (link).

Help with App Compat Issues

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. 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 the window manager. 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 properties. Here is a link for more info on how to do that: http://windowshelp.microsoft.com/Windows/en-US/help/bf416877-c83f-4476-a3da-8ec98dcf5f101033.mspx. (Look at the section for “Disable Display Scaling on high DPI settings”.)

How is DPI scaling different from per-application scaling (like IE Zoom?)

A typical application UI is made up of a content window and a frame UI. The frame UI is where the menu items and toolbar buttons are. The content window is the “document view”. For example, in IE the content window is the actual webpage. It turns out the code required to support high DPI scaling for the content windows is the same code required to do the zooming feature. In fact, for the content window, IE8 simply uses the high DPI setting to configure the default zoom factor (see DPI Scaling and Internet Explorer 8 for more details). However, high DPI has the additional side effect of scaling the size of the frame UI. Since most people use the scaling feature to make text larger to be more readable, it makes sense to scale the frame UI as well, since the text in the menu items and toolbar tooltips will also scale. In a sense if there is per-application scaling that is really about the content area, and applications will support that as developers see the customer need. DPI scaling makes the UI elements of all applications render similarly.

Shouldn’t DPI really be used for calibrating the screen (so “an inch is an inch”)?

Some have suggested that we should just use high DPI as a way to calibrate the screen so that the physical size of an object is the same regardless of the display. This makes a ton of sense from a logical perspective. The idea would be to calibrate the display so “in inch is an inch”. We thought about doing this, but the problem is that it does not solve the end user need of wanting to have a way to configure the size of the text and the UI. If we then had a separate “global scale” variable, this would mean that application developers would need to pay attention to both metrics, which would add complexity to the developer story. Furthermore, if a user feels that the UI is too small, should it be up to the developer or the user to set the preference of how big the UI should be? In other words if the designer wants the button to be an inch, but the user wants the button to be 1.5 inches to make it easier to use, who should decide? The way the feature works today, it is up to the user to set their preference, but it is up to the application developer to make sure that the user preference is honored.

Once again, it is really great to see so much interest in high DPI. We certainly have some challenges ahead of us, but in many ways it seems like the ecosystem is ripe for this change. Hopefully this follow up post helped to consolidate some of feedback which we have heard on the previous post and explain some of the complexities of this feature in more detail.

--Ryan Haveson

Leave a Comment
  • Please add 4 and 7 and type the answer here:
  • Post
  • OK, we are all using LCD and we all know LCD works best at native resolution. So, we need to set resolution to 1920x1200 for a 24inchs screen. Everyone agrees right?

    What's the problem?

    When we use native LCD resolution, everything is so small. It was fine with small display era. We moved on. Most of us uses screen larger than 20 inchs. We use large screen for what? No, not because we want to see more text. We just want to feel more comfortable, like watching TV. Apparently everything stays tiny.

    Two options, use lower resolution or high DPI. If you ask me, high DPI is a joke. Many things breaks. IE8 still renders tiny fonts, high DPI is useless. So the only good solution is lower resolution, sadly LCD won't display it nicely.

    Screw DPI, seriously. We should focus on default GUI size and font size using native LCD monitor resolution. We should make it larger by default, so we don't have to mess with DPI at all.

    There is no point of DPI problems, when we don't want to change DPI. We simply want GUI easy on the eyes. We don't want to change DPI at all. If someone wants tiny text, they adjust DPI then. Most of use don't want to change DPI. We want larger GUI and text. Forget about DPI. We don't want to change DPI.

  • magicalclick:

    A good example of a comment where the solution is blinded by personal preference. There are PLENTY of users who require DPI information. CAD, Desktop publishing, and image professionals all need to know that what they're seeing on screen matches the output they're going to get offline. Apple came up with ColourSync specifically so that image professionals could be sure that the colours on screen were what they expected to see on paper. The data shown previously proves that "most of us" do not use 20"+ screens at all, and a large majority don't use LCD's either.

    People who are buying large screens are doing so for a variety of reasons, some for games, some for video, some for ease of viewing, and some for increased real estate. (The fact that CRT monitors still provide clearer visuals is a depressing state of affairs).

    Personally, if I bought a 30# screen, and found that the GUI scaled itself up to grab back some of my expensive new real estate, I'd be pretty pissed off.

    Bring back a decent version of Windows Explorer.

  • When XP was new there was a lot of talk about DPI. As I remember it, it was for a short time a requirement that your application could handle different DPIs in order to get the "Approved for XP" stamp. That requirement was later dropped.

    We have a type of customers where many users have very big screens (financial markets) or multiple screens. At the time we thought it would be nice to support higher DPI in our applications that were mostly developed in C++/MFC at the time. One problem was that even several standard components, such as the ComCtrl Calendar control, provided by MS, did not handle high DPI well. It turned out that many other applications used by our customers did not work with high DPI either. Even some of the utilities in XP did not work perfectly. Office had several problems. It was obvious that MS were not serious about this and when they removed the requirement from the "approved for XP" logo program, we dropped the idea.

    I have not tested recent versions of Office, but I think that in order for this to happen, a first step is for MS to make sure that their own applications can handle it properly.

  • Vector icons should be allowed, even though they will obviously not replace raster format icons. Perhaps even allow .icos (or another format if you're worried about standards) to contain vector versions of an icon. That way icons above, say 128x128 could still be displayed at any resolution at vector quality and raster icons can be used at the 64x64 and lower levels.

    Just a suggestion - obviously it's a bit of work and difficulty for something that might not be used a whole hell of a lot. And it does make extra work for the artists. But it'd be nice to have the extra flexibility.

  • I agree that vector graphics isn't the solution, but I think Microsoft's long history of teaching developers to design GUIs using unit-based coordinates should take a lot of the blame for the current problems.  Designers need the freedom to position elements with pixels or scale them by text, and you can't just slap the same 'DPI' value over everything.  Just the other day I read in Vista's User Experience Guidelines that you should leave 30% extra space on a label for internationalisation.  It's arbitrary sizes like that that cause problems when the font size changes.  We should all take a lesson from HTML or cross platform GUI toolkits and start using proper layout containers to position our controls.  I try, but Microsoft don't help.

  • I can't believe you haven't mentioned Windows Presentation Foundation yet. If developers use this technology to build their UI, it _is_ a silver bullet: your applications will be DPI-independent.

  • After reading the last blog post, I made a little app that calculates what DPI a certain size screen at a certain resolution should be.  I found that my 17" CRT at home (which, btw, is miles better than the Dell LCD I have at work) is at 101 DPI at the resolution I run it at (1280x960).  So I changed Vista to use that DPI and I'll be darned if things don't look better.

    The easy fix for Windows 7 is to detect the native resolution of the display and the size of the display, and automatically adjust DPI to match.  Of course, leave the option in to adjust it, but I think for most users this solution will work.

    And to the poster above who claims that "most people" have displays 20" or larger...what planet are you on?  I don't know anyone who has a display that large except for my one friend who uses his 42" TV as a computer display.  I'd imagine the more common size is 17" 4:3 and 19" 16:10.

  • Oh... the poor horse.  Couldn't you just create different sized vector versions?  Please focus on the benefits of vector graphics rather than this one little issue.

  • But isn't two vector images (one for med to large to ultra-super-insane-large [eg. scalable], and one for minuscule sizes) less costly on hard drive and memory than 6 separate raster images at various sizes which may only go from small to large (and have no way to scale to any size without pixelation)?

    I think for now vector and raster should be allowable since the artists decide weather or not to use raster, but I think vector is better in the long run.

  • [Microsoft] Ryan Haveson

    spivonious and others have asked why we can't just set the DPI automatically.  

    It turns out that there is a communication protocol specified for the display connection so that the operating system can query the display to find out information such as display native resolution, refresh rates supported, and physical dimensions.  The data structure that is transmitted is called the “Enhanced Display Identification Data” (EDID), and it is an industry standard specified by the Video Electronics Standards Association (VESA). Based on the physical dimensions and the native resolution reported by the EDID, we can calculate the display native DPI.  Using result of this calculation we can set the DPI to a default value.

    In order for this to work correctly a number of things have to be true.  First, the EDID communication link between the video card and the display must be working.  Though the EDID is sent over the standard display connection, sometimes when the connection is indirect (like through a switchbox), the EDID information is not properly transmitted.  Second, the display must return a well-formed EDID with valid data for physical dimensions. Since this parameter is rarely used, it is sometimes not set correctly by the hardware manufacturer.  When all things are working, we could set the DPI to a default value. However, since the text size is a per-user preference we still need to make sure it is easy for users to choose their own DPI setting because the default is likely only to satisfy ~75% of users.  And then of course we have to think carefully about doing this automatically because of the app compat risks discussed earlier.

    This is a classic example of the sort of decisions that we have to make at a very granular level all the time in Windows.

    --Ryan Haveson

    Microsoft

  • divil,

    Although WPF is a really great solution for the most of the problems of scaling UI, it still needs the developers to follow some rules. In particular, as many books an docs advise,  explicit sizes and positions should not be used, letting layout system do its work. But most of programmers still use explicit values habitually.

  • I agree that vector graphics files may become large, but it also depends on the format that is used to create and store it.

    Maybe, it would make sense to have a "slim" SVG format that may be suitable for icons? Call it Icon Vector Graphics (IVG), if you want. The files can be stored in compressed format(IVGZ). Current hardware should easily handle storage and rendering of such icons. The designers will eventually learn on their mistakes; for example, if they use lines that are too thin for smaller format images.

    And, bitmap icons can be used for both legacy and new applications, IVGZ being the preferred format.

    Ideally, I would like to see the contents appear the same size, no matter what size the monitor is, after an out-of-the-box Windows installation.

    Another reality fact is that CRT monitors are hard-to-find these days. Most companies have already switched to LCDs which typically have relatively high DPI, and small fonts and images on such monitors is definitely a big concern, and we should not overlook it.

    Opticians should be involved in the process to find the optimal sizes for fonts, icons, etc. to create minimum strain on eyes for the majority of the users, including people with vision that is not perfect.

  • What tools are designers and developers are using to create icons? Visual Studio is not the best tool for it.

  • Wow, I really learned a lot from this one. Good to see you guys dropping deep into continued visual improvements and pushing the technology foward. My biggest concern is taking all of the discussion and tools here and making sure that every graphics card maker and motherboard maker executes on their end. It took a good year after Vista was launched to get decent drivers so we could see Vista as it was meant to be.

    nVidia and ATI was lazy about it. So was Intel and other board makers with onboard graphics. Instead of resting on their laurels and just using Vista created drivers for Windows 7. I really hope Microsoft and the Windows 7 team really puts the pressure on.

    Also, developers have been lacking in working with Vista's new tools. Another respondent said, we don't see a lot of developers implementing the WPF in products. Its time to get them onboard and executing with all these tools and techniques, so that the 7 experience is even better than Vista.

  • @Steven Sinofsky

    Im Italian, excused my English. I wanted to open a parenthesis in Off Topic.

    They are a WIndows user from years, and are a lot much happy.

    Personally creed that Vista is a system extraordinary, that it has received much FUD from the Media.

    This evening I read quest' article  http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9114865

    I would not want that the FUD was repeated also with WIndows 7, In small part from good user I have sent all those which were my ideas (perhaps stupid do not know it)

    But a thing is sure, is 2500 Engineers to job for Windows 7, perhaps you do not have not even need of our comments

    I pray to you, you put once in Hush and for all the FUD against Windows.

    You are persons of great talent, and we answer to this people who call journalists or blogosfera, with the facts

    Thank's

Page 1 of 4 (48 items) 1234