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:

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 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: (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 4 and type the answer here:
  • Post
  • Most of what people are asking for seem like bug-fixes.  I guess I feel that it's kind of a waste.  It feels that the computer power is available to have a truly powerful UI in respect to re-sizing.  I want the ability to shrink or enlarge the clock at the bottom right of my screen..  Sure it might take some arcane key-combo..  But I want to be able to change the fields in the applications..  is the location-bar unreadable... change it ON the FLY  The tabs taking up too much space.. shrink them.  

    Build the tools so that the app developers can allow for this sort of interaction.  And adjust accordingly.

    Step into the 21st Century and go with extrordinary new work rather than a patch job on a passable peice of code.

  • @Ambition - I have to say I love your idea with the hybrid Raster/Vector Ico files.

    Between that and WPF Windows should be covered for on the DPI front for the most part.

  • tempest raises a good point, it be nice to make any icons on the screen small but leave the task bar or the side bar at the same size. This would be nice, sizable objects in the UI, I run all of my LCD's at native resolution, I have a 17 inc LCD for the family computer and a 22 inch wide screen for my personal gaming computer. I like this.

    Red Union

  • I like the way that Vista does icons with all of the different sizes included in one .ico. I can scale Microsoft's icons much larger than I would ever need them and they look great. The problem is that other developers do not include nice icons like this. I have used Axialis IconWorkshop to easily create beautiful icons from other images. If easy tools like this were available to more developers I think the problem would be solved.

  • Basically what I have gotten out of these last two posts is this. You want to make the user experience better by making graphic more consistent.

    Right now there are several different problems that conflict.

    1. Having computer resolution match native screen resolution.

    2. Having items on the screen be the correct size.

    3. Not breaking old applications with new changes.

    My solutions:

    1. Have windows choose the correct resolution on install and when a monitor is added. The only reason a user should want to change the resolution is for performance (FPS in video games). Resolution should be completely independent of size. Therefore, the ability to change resolution should be moderately hidden (in the default Windows UI).

    2. To fix the size issue, users should be given a choice on install of how big they would like their text/images. Show several samples so that they can make an educated choice. As much as people may disagree with me, once that choice is made, all non-scalable graphics should be scaled as bitmaps. Windows frameworks/best practices should include ways to use scalable graphics in all UIs, but still include a way to use 1 or more bitmaps of varying sizes.

    3. None of my proposed solutions should break old applications. Almost all applications can already handle multiple resolutions. In addition, when a person chooses to use smaller or larger objects on the screen, old applications can be scaled as bitmaps.

    Note: I never used DPI in my explanation of the problem or solution. The concept of DPI confuses most end users. By using a concept that many people already know (resolution) and one that is very easy to understand (size), there is no need to burden the users with learning another concept that should not effect them.

  • Maybe the problem with many DPI-automagicality issues (basically, single-pixel lines and other blurring) is that DPI has to be increased substantially all at once, not by a small margin. If you try to increase it 30-50%, all these problems surface with a vengeance. Increase it 100%, and scaling is perfect. Even bitmapped icons and images will look very good, with the right upsampling filter.

    I've used high-DPI screens in combination with high DPI settings, and I own a Sony Reader. The result is simply beautiful. I'm talking about the same sized windows but at high fidelity. (Remember, there's really two very different angles to the whole DPI debate.. people whose vision is worse than their display and people whose vision is better!)

    Orchestrate with industry to make the leap. Not a hop, but a leap to 192 DPI, and customers will appreciate the new "HD" PC. Then momentum will build to get applications working at intermediate sizes as well.

    P.S. The raw LCD technology for 192 DPI is entirely feasible. IBM released a 204 DPI monitor over seven years ago. No one makes such monitors anymore because software can't use them (or customers are too clueless to use them right). The flat-panel industry needs a spark to start making them again. But you're freakin Microsoft. You can move the world.

  • PRab if i read you right - your concept, 'size' is the same as the concept of DPI (though size really is a more relatable term).

    The issues remain:

    1)scaled bitmaps look fugly

    2)some UI elements don't scale at all.

    I'm still trying to understand a third (possible) issue: if the frame ui is scaled - is the content window scaled? is it non issue?

  • I always thought i was good at paying attention to detail...but the sad truth is before these posts i never really looked at icons directly... i had apparently only recognized them by shape, color blends, and placement on my desktop...i have used ccleaner for a long time and never realized it was a broom over the icon...same type of thing with all the other icons...

    while on the other hand i can tell in 5 seconds if a crt is set to 60 hz refresh rate or 2 seconds if an lcd monitor is not set to its default setting...

    so perhaps the more important issue would not be icon details but icon crispness..

    if one were to use vector graphics, which from what i gather a lot of people like the idea of (build it once, not six times) is an idea...subject a rule into the vector graphics for icons to never half a line/pixel...start the icon with good detail at say 3X larger (for use on those hdtv in their living rooms) than what would be normal the icon scales down...things just disappear but the whole image is still really crisp...using windows xp icons as an example...the little green light on my computer would disappear...the subsections of the tower part of this icon also disappear...on the my documents folder icon the part of the upper corner that folds down disappears...etc....

    the point is that no icon looks like any other icon...its part of they actually dont need to be too elaborate ...

    just by following a simple rule of thumb..eliminate the half pixel/line on downsizing and donate the half pixel/line while enlarging....leave anti-aliasing up to the gamers

    obviously text still needs special treatment ...its after all what we really look at on a computer screen (most of the time)....


  • I think you've made the vector scale issue look worse than it is.  Yes at extremely small scales the same vector image will look poor, but the range that it looks acceptable is much larger.

    Also something similar to the gaming LOD could be used, to mask parts that could be skipped a certain scales.

    As for the size, I think people would rather spend the disk space on a better looking OS, than some of the other 'bloat' that we currently get.  

    btw are there any os's/guis that use a pure vector approach??

  • I am dreaming a world where ... an inch is an inch on any output at 100% zoom by default. We may zoom at any percentage we want and keep the correct look. All output devices, applications, graphics cards and operating systems, report the DPI, the horizontal and vertical dimensions, and the number of colors they support. They all use the same vector based print language with bitmap support for UI. Something like the bitmaps that cover the (vector) meshes in 3D games. Everything looks the same on any output in landscape or vertical orientation. There is also a universal agreement that 16:10 is the default - horizontal to vertical - ratio for all outputs like paper, monitors (desktop, laptop, cellular) etc. I love it. 16.18/10 is the golden ratio (divine proportion, phi).

    Then I woke up

    I live in a world where I have no way to print a picture with Vista's print manager and calculate the output dimensions. An inch is never an inch. 100% is meaningless... You know the rest. I prefer to make myself a coffee now.

  • I'd like to add that I have a CRT monitor capable of 1600x1200, but I use 1280x1024 for technical reasons - it only supports 85Hz refresh rate @ 1280x1024, using 1600x1200 it would operate at 60Hz which is not comfortable to the eyes.

  • I'm looking into this discussion and have another 2 cents:

    I was trying to install MS Office 2007 on PC with high DPI. It was looking much worse than Office 2003 (which was used earlier) and I had to return to 2003. Why ?

    Let's say Outlook - interface very big and scaled, folders names in Navigation Pane big, emails preview in the bottom of the screen extremly small, emails preview in the right side big. When I tried to write some plain text email, text was more than extremly big...

    We can speak about technology here, how to make scaling etc. etc. But it doesn't change fact, that adding one simple config box with options: scale/don't scale this and this (for example ribbons) & use such and such font for displaying it will resolve problem for 90% of users.

    In the example below I wasn't able to change font used for displaying menu (standard one was very "soft") and I wasn't able to make things displayed with fonts with almost same size.

    Maybe full automating scaling can be done and it will be revolution. But for now such config will be nice and enough (Steven - it would be nice to have in Office 2007 SP2 :)).

    ...and once again: problems will not happen, if there will be on the market devices with different pixels size (I speak here especially about notebooks - 0.29 pixels were more than excellent, 0.25 and small are SMALL). Microsoft CAN make something for convincing manufacturers for making such devices. Maybe another sticker ? For example something like: Large/medium/small fonts.

  • I assume most designers use Illustrator, which has a XAML converter.  Expression blend icons look sexy when done right.  True 3D icons are cool too because they can rotate, wiggle, shake, and get jiggy on your screen :)

  • sich, you're right that using layout in WPF is by far the best way to go to avoid DPI issues but if you do use explicit values then they'll scaled based on the DPI. "Pixels" in WPF are set at 1/96th of an inch rather than true device pixels.

  • "Shouldn’t this just work without developers having to do anything?"

    I think you read too much into that. I doubt many people seriously believe it can be toggled on just like that, without requiring any effort from the developers. But it's obviously not a black/white issue either. It's not "either the OS does all the magic for us developers" (impossible), or as you seem to think "We provide some educational material and a few new API's, and then the developers do all the work".

    True, there is no silver bullet, but there are far better ones than what is currently exposed by the OS. WPF is nice, but it's not the OS. It is not available if I'm not running .NET. The OS itself must expose *better* tools for DPI-independence. Not perfect, of course, but *better*. And it must actively encourage these. As long as they coexist with all the old cruft which doesn't even know what DPI means, people will use the APIs they're familiar with. Of course there has to be some way to specify per-pixel UI when needed, but it should not be the default, and the API should make it clear that this isn't the best way to go in general.

    And of course, another important note is the chicken and egg thing. No one's going to write DPI-indpendent software as long as no one uses the DPI settings. When everyone changes their resolution instead of changing DPI, there's just no point. The day Windows makes it easier for the user to change DPI than resolution is the day software will start handling different DPI settings correctly. The zoom bar in the WPF designer in VS comes to mind as a good example here. It's easy to find, it's much more powerful than a drop-down with a few predefined zoom settings, and it just works. Windows needs something like that. (Not exactly a zoom bar on the desktop, probably, but something equally flexible and powerful, and equally intuitive and easy to find. Something that makes users change DPI instead of resolution)

Page 2 of 4 (48 items) 1234