More Follow up to discussion about High DPI


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

Comments (48)
  1. magicalclick says:

    OK, we are all using LCD and we all know LCD works best at native resolution. So, we need to set resolution to 1920×1200 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.

  2. Hairs says:


    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.

  3. Thriol says:

    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.

  4. Ambition says:

    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 128×128 could still be displayed at any resolution at vector quality and raster icons can be used at the 64×64 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.

  5. hh10k says:

    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.

  6. 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.

  7. spivonious says:

    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 (1280×960).  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.

  8. Kosher says:

    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.

  9. jimbo2150 says:

    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.

  10. ryanhaveson says:

    [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


  11. sich says:


    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.

  12. RuslanUrban says:

    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.

  13. RuslanUrban says:

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

  14. hitman721 says:

    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.

  15. domenico says:

    @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

    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


  16. tempest says:

    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.

  17. Yert says:

    @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.

  18. redunion says:

    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

  19. Cartman05 says:

    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.

  20. PRab says:

    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.

  21. alex_dubinsky says:

    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.

  22. jaips says:

    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?

  23. TopTwoPercent says:

    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)…here 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 size…as 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 branding…so 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)….


  24. cjb110 says:

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

  25. mariosalice says:

    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.

  26. ricardog says:

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

  27. marcinw says:

    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.

  28. Kosher says:

    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 🙂

  29. iantaylor says:

    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.

  30. Jalf says:

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

  31. brian.shapiro says:

    I think the idea that vector based icons not having different presentations for different sizes is missing the point.

    If Windows ever does use vector based icons it should still have three sizes for small, medium, and large, because developers want the icon to fit an interface designed for small, medium and large icon sizes.

    However, the point is that the small icons look the same at higher DPI but with higher detail per the resolution, and large icons still look different from small icons at higher DPI.

    Right now if you scale up the DPI, you have icons designed as 32×32 or greater on the taskbar, which doesn’t fit in. The higher DPI icons should look exactly the same as a 16×16 icon but with detail to match the resolution.

    That’s why vector icons are a good idea, but multi-size vector based icons.

  32. teoh.hanhui says:

    It would be nice if Windows could do "downscaling" seamlessly to create a perception of lower resolution while actually displaying at the screen’s native resolution. This would ensure full compatibility and lessen the burden of software developers.

  33. magicalclick says:

    I am not going to argue how you are going to push the tiny font world.

    First you claim that many people turn down resolution because everything is tiny for some people. Then, you introduce DPI as a way to display larger fonts on high/native resolution.

    Here are two things from Microsoft failed to support High DPI uses on usability issues.

    1) IE8 Beta 2

    HTML rendering is totally unaffected by DPI setting. Everything is simply small on IE8 Beta2. The text size setting in IE8 won’t work on many sites, like Gamespot Forum. So, the only robust solution on IE8 is using Zoom. Sadly Zoom performance is extremely bad. IE8 is the first program I know to ignore DPI setting. This is from Microsoft and this is Microsoft’s solution to DPI setting.

    2) Window Live Messenger 9 Beta.

    Everything is big as DPI affects everything. Looks like WPF kind of effect where image is also scaled by DPI. BUG, the online status drop down list shows no text when using 144DPI. I don’t know the regular 120DPI, but the fact is WLM9 Beta failed on DPI. So, here is the solution about Microsoft adapting DIP setting. Bugs Bugs and more Bugs.

    Both Microsoft popular software failed to follow the DPI guideline properly or without bug. So how can you expect anyone else not to mess up? Again, DPI setting is garbage when even MS can’t do it right.

  34. Edward C says:

    Speaking as a developer, please do. When I develop an application that displays a user’s work at "100%" I want that work to be the same size on screen as it is on the printed output. If that user wants to scale up their interface so menus, buttons and labels get bigger, I want them to be able to do so, while keeping their work the same size on screen – if they want their work to be displayed at a larger size, they’ll select a different zoom level. Call me crazy if you must, but I think a setting called "Dots Per Inch" should reflect, well, the number of dots per inch, rather than the-setting-that-was-named-after-dots-per-inch-but-isn’t-really-about-dots-per-inch-but-uses-that-value-as-an-arbitrary-start-point-for-some-kind-of-poorly-defined-global-scale-setting. If that level of flexibility introduces the additional complexity of sometimes having to multiply by another variable, well that’s the kind of sacrifice I’m willing to make.

  35. Prixsel says:

    On Windows XP few people know how do make text look better what should be enabled by default

    For text sharpener >> Desktop > Right Mouse Click > Properties > Appearance > Effects > Use text method called Clear Type

    So making Clear type as default would be wise choice…

  36. palotasb says:

    Prixsel: How’bout Vista? It already has ClearType as default.

  37. magicalclick says:

    The new Live Map just got updated recently. Guess what? Another DPI bug. I am using 144DPI. When I use Live Map for direction, the direction line is screwed up. The line is drawn in a smaller scale than the map.

    So now, MS failed 3 times.

    1) IE8 HTML rendering ignore DPI.

    2) Live Messenger 9 has empty status drop list using high DPI.

    3) Live Map direction line screwed up at high DPI.

    What’s next? Windows Explore has a missing back button when using high DPI? This is why I am so frustrated. All the talk about DPI when MS failed to follow DPI guideline. Not enough people cared because they never know how painful for users like me using buggy high DPI setting.

    I am seriously thinking about trying other OS and see how they deal with this. Personally I wouldn’t touch DPI if everything is not in tiny land.

  38. ryanhaveson says:

    [Ryan Haveson] (Microsoft)

    @magicalclick:  For what it is worth, the issues you raise with the Live applications are known issues and the team is working on them.

    I also want to say that I know it is annoying when things don’t all work as expected, and I know it is even more annoying when people try to talk you out of your frustration so I won’t try to do that.

    Awareness of the value and importance of this feature is growing both inside and outside Microsoft and over time I hope to see fewer and fewer "deal breaker" app compat issues and customer scenarios.


    –Ryan Haveson


  39. Lonn says:

    Lonn [Microsoft][Windows Live]


    The Windows Live Messenger team is aware of this issue and is working on a solution.  As we’re still in beta, it’s great to get feedback like this so that we can ensure the final release is something we’re all proud of.  Thanks.

    -Lonn [MSFT]

  40. magicalclick says:

    @Lonn [MSFT]

    Thanks for working on the case. About Live Map. I tested it on IE7, which is fine. When on IE8, both Live Map and Google Map experience the same direction line bug.

    Hope this helps you guys narrow down debuging surface.

  41. Astellar says:

    Generally windows handle DPI different from 96 terribly. As an example I specify my monitor DPI as 127 DPI, and what I see, I see ugly scaled icons, I see MS office quick access bar in with a wrong alignment. And a lot of 3rd party programs display blurred text, which looks like an out of focus image. A lot of details look oppressive. It is shows that MS did not consider any other DPI except 96, but for HD monitors it is not acceptable.

    I know that this message will be ignored, and MS will newer looks into such deep details, but I the main impressions in a details and I hope that such defects will be fixed.

  42. Igor Levicki says:

    I would suggest the following:

    1. Leave DPI for calibration

    That can be set by user during setup or just extracted from the monitor DDC info.

    2. Make all UI elements separately scalable including Shell Dlg font.

    User preference on that matter should be final — it should override any application "design".

    Your studies on High-DPI should include testing with visually impaired people and different age groups.

  43. dmitriid says:

    I’m sure this has been mentioned before, but still. There’s also the issue of nice fonts. Here’s an article by the author of the excellent AntiGrain library:

  44. amirpro says:

    Microsoft has so many great technologies, but it never use it.

    For example, WPF exists for more than a year but there is not even single one MS application (except of the Expression Studio) that uses it.

    WinForms and .NET 2.0, exists for more than 3.5 years, but MS Office 2007 and the rest of MS apps are still using the ancient GDI/MFC and win32 APIs.

    It seems that MS does not trust its own technology, or doesn’t want to invest in migrating it’s apps to use it.

    It’s a real shame, Vista and Windows 7 could be so much better OS if MS would just use WPF for rendering the OS itself. Old API’s such as GDI and MFC should be there just for compatibility reasons with old apps.

    One last thing, Ryan, could you ask Vista devs to release a hotfix for the poorly upscaling of icons in high-dpi modes? (for some reason when the icon res is lower than the drawing size, it’s being upscaled using NearestNeighbor instead of Bilinear – you can’t miss it, it’s a cross-platform bug that affects all applications, including the OS UI itself). I figured out that GDI+ solves this problem as it set Bilinear as the default interpolation mode, but old GDI/USER32 fellows does only downscale with good quality, but upscale is bad.

  45. TanjB says:

    I’ve been using LCD since 1993 and experimenting with DPI ever since.  I currently have a 30" monitor at 2560×1600 and a laptop with a 15" monitor at 1920×1200, and I set both of them to 120 dpi, for slightly different reasons.  I’m often looking at Japanese so the high res on fonts is a great improvement on the complicated glyphs, plus the better drawing of alphabets makes them easier to read.  I cannot tolerate ClearType because it looks fuzzy, while higher DPI has no drawbacks.

    Over time the bugs in software have declined.  In the 90s it was a real pain.  The remaining problems are focussed in areas like Dialogs with clipping and miscalculated button positions, plus apps like browsers (including Firefox variants) which are total throwbacks and insist on drawing everything at the pixel level.

    In summary there is no reason why 96dpi should be engraved in stone.  Technology allows higher resolutions and the human eye appreciates it.  It is well overdue that software writers use a resolution independent drawing model and liberate users to get the best out of improving hardware.

  46. cirurgia plastica says:

    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.

  47. Texas Driver education says:

    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.

  48. 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 128×128 could still be displayed at any resolution at vector quality and raster icons can be used at the 64×64 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.

Comments are closed.

Skip to main content