Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
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:
There have also been a number of areas where there has been a bit of confusion:
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.
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.
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:
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.
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).
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”.)
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.
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.
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 32x32 or greater on the taskbar, which doesn't fit in. The higher DPI icons should look exactly the same as a 16x16 icon but with detail to match the resolution.
That's why vector icons are a good idea, but multi-size vector based icons.
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.
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.
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.
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...
Prixsel: How'bout Vista? It already has ClearType as default.
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.
[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.
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.
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.
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.
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.
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: http://www.antigrain.com/research/font_rasterization/index.html
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.
I've been using LCD since 1993 and experimenting with DPI ever since. I currently have a 30" monitor at 2560x1600 and a laptop with a 15" monitor at 1920x1200, 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.