Hi,
It is my understanding that Vista has the ability to scale all text sizes
according to the display resolution (i.e. 12 point fonts will actually be 12
ponts regardless of the display resolution). Has this capability been
implemented in Vista Beta 2? If not, is it going to be? I have tried it out
with Vista Beta 2 and the text sizes still decrease as the monitor resolution
increases.
Thank you kindly.
This is not a programming question but I'll answer it anyway.
In Control Panel, search for "dpi" - there will be one hit. Click it.
I was referred to this forum from the MSDN Managed Newsgroups forum. If this is not the correct forum then please refer me to the right one.
Let me rephrase the question, does Vista programatically scale font size according to the monitor resolution? In other words our customers will NOT have to reconfigure their monitor settings (i.e. dpi settings) to view the texts on our application when they migrate from the 1280x1024 resolution to the 1600x1200 resolution.
My understanding is DPI scales with screen resolution (i.e. as the resolution increases the size of each pixel descreases). So 1 inch represented by on a 1280x1024 resolution at Window's default 96dpi will be longer then on a 1600x1200 resolution. Hence text that are not TrueTyped becomes smaller as resolution is increased.
Question: Will Vista be able to obtain the monitor's viewable area size to work out the DPI setting that windows should be set at and set it instead of having the DPI set at 96 dpi all the time.
Physical DPI changes with resolution but logical DPI does not. When msot people spend $1000 on a monitor with higher resolution, they want to be able to see more stuff. They don't want to see the same stuff magnified. I don't know whether the monitor sends its physical dimensions to the computer.
I've been reading that Vista will scale fonts for high dpi displays. What I read into that information is that a 12point font will be 12 points no matter the resolution (i.e If I pick a font that is one inch high on my monitor at 1024x800 it will be one inch high at 800x600).
I guess after further thought it doesn't make a lot of sense though.
Unfortunately the word "resolution" has been distorted from its original meeting, which is virtually synonymous with DPI. Many people (and the Windows UI) refer to the screen's size in pixels as its resolution. Not everyone has adapted their usage of the word.
If I spend $1000 on a larger monitor with the same physical DPI, I expect to see more stuff. But if I spend $1000 on a same-size monitor with a higher physical DPI, I expect better, er, resolution. In other words, I expect my text to be the same size, but rendered more clearly. Setting the logical DPI to something other than the physical DPI is a hack to trade off accurate WYSIWYG for either more legibility or more screen real estate.
Most Windows machines have logical DPI set to 96, which was pretty close to the truth for many monitors for many years. Physical sizes and total pixel sizes tended to go up together, leaving the physical DPI very close to 96.
Font scaling is often not linear: the characters in a 10-point font are not necessarily exactly 25% wider than the characters in the same font at 8 points. Instead you'll find they're a little bit wider, in order to make them look balanced at when rasterized. Similarly, rasterizing at a higher DPI won't necessarily give you proportionally-sized characters (in pixels).
This means your UI layouts may not scale well when the logical DPI is changed. As resolution gets high enough, the problem tends to go away. The jump from 96 to 120 DPI can cause pretty drastic differences.
Dialog units were intended to help ameliorate this, but, unless you include enough padding, they aren't precise enough to handle everything. The ideal solution would be dynamic layout based on actual font metrics, but historically that wasn't practical. Even today, it's difficult to implement.
Many programs were written and tested for machines assuming 96 DPI. If you change the logical DPI to something else, you might see clipping, overlap, or egregious spacing.
At last, we have monitors that have significantly different physical DPI. Some small screens in portable devices, for example, go up to 144. High-end desktop monitors can hit 200 or more. With these, it's no longer practical to leave the logical DPI back at 96--the text would simply be too small to read. But if your program was only ever tested at 96 DPI, you might encounter layout problems.
By default, Vista lies to programs. It tells them the resolution is 96 DPI, then it scales the UI like a bitmap (linearly) to the logical DPI setting for the system. This mostly ameliorates the layout problems (though not completely, for the same reasons dialog units weren't good enough) at the cost of some fuzziness when the logical DPI is set to something other than 96.
If a program has been careful to design and test for a range of DPIs, it can tell Vista that it's "DPI-aware" to stop the lies and the scaling. There are rumors there is a way to do this in the application manifest, but I haven't found any documentation for it. Instead, you can call SetProcessDPIAware before you create any UI.
SetProcessDPIAware is a new API for Vista. If your program needs to be backward compatible to pre-Vista versions of Windows, you can use LoadLibrary and GetProcAddress to see if SetProcessDPIAware is available before calling it.
