More Follow up to discussion about High DPI

Makale
09/16/2008

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.

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: https://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 https://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: https://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

Comments

Anonymous
September 16, 2008
The comment has been removed
Anonymous
September 16, 2008
The comment has been removed
Anonymous
September 16, 2008
The comment has been removed
Anonymous
September 16, 2008
The comment has been removed
Anonymous
September 16, 2008
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.
Anonymous
September 16, 2008
The comment has been removed
Anonymous
September 17, 2008
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.
Anonymous
September 17, 2008
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.
Anonymous
September 17, 2008
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.
Anonymous
September 17, 2008
[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
Anonymous
September 17, 2008
The comment has been removed
Anonymous
September 17, 2008
The comment has been removed
Anonymous
September 17, 2008
What tools are designers and developers are using to create icons? Visual Studio is not the best tool for it.
Anonymous
September 17, 2008
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.
Anonymous
September 17, 2008
@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
Anonymous
September 17, 2008
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.
Anonymous
September 17, 2008
@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.
Anonymous
September 17, 2008
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
Anonymous
September 17, 2008
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.
Anonymous
September 17, 2008
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.

Having computer resolution match native screen resolution.
Having items on the screen be the correct size.
Not breaking old applications with new changes. My solutions:
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).
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.
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.

Anonymous
September 17, 2008
The comment has been removed
Anonymous
September 17, 2008
The comment has been removed
Anonymous
September 17, 2008
The comment has been removed
Anonymous
September 17, 2008
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??
Anonymous
September 18, 2008
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.
Anonymous
September 18, 2008
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.
Anonymous
September 18, 2008
The comment has been removed
Anonymous
September 18, 2008
The comment has been removed
Anonymous
September 18, 2008
The comment has been removed
Anonymous
September 19, 2008
The comment has been removed
Anonymous
September 19, 2008
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.
Anonymous
September 20, 2008
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.
Anonymous
September 21, 2008
The comment has been removed
Anonymous
September 22, 2008
The comment has been removed
Anonymous
September 23, 2008
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...
Anonymous
September 23, 2008
Prixsel: How'bout Vista? It already has ClearType as default.
Anonymous
September 24, 2008
The comment has been removed
Anonymous
September 25, 2008
[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. thanks, --Ryan Haveson [Microsoft]
Anonymous
September 25, 2008
Lonn [Microsoft][Windows Live] @magicalclick 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]
Anonymous
September 27, 2008
The comment has been removed
Anonymous
September 29, 2008
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.
Anonymous
September 30, 2008
The comment has been removed
Anonymous
October 06, 2008
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
Anonymous
October 07, 2008
The comment has been removed
Anonymous
January 08, 2009
The comment has been removed
Anonymous
August 15, 2009
The comment has been removed
Anonymous
November 23, 2009
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.
Anonymous
April 24, 2010
The comment has been removed

Aracılığıyla paylaş