During our accessibility test pass this week, we’ve also been looking various display settings like high DPI settings. DPI stands for “dots per inch” – the number of pixels per inch on your monitor. By default, Windows draws at 96dpi. However, higher resolution monitors are becoming more and more popular. These screens squeeze more pixels into the same space, given you a much crisper/clearer picture. For example, the Dell Axim x50v Pocket PC has a 200dpi 640×480 screen that’s less than 4 inches high. The result is incredibly sharp text and graphics rendering.
As higher resolution monitors become cheaper and more prevalent, testing your application for high dpi readiness will become more critical. Luckily, you do most of your testing without needing to spend megabucks on a high dpi monitor. Here’s how.
On Windows XP and Windows Server 2003, you can adjust your PC’s dpi setting by:
- right click on the desktop and choose “properties”
- click to the “settings” tab
- Choose the highest display resolution available for your monitor
- click the “advanced” button
- On the “general” tab, choose “Custom” for “dpi setting”
The quickest way to check your app for high dpi readiness is to choose the highest setting – say 200%. This equates to 192dpi which, on a normal 96dpi monitor, will make things look a bit funny. When you do this, Windows will scale up icons, text, buttons, scrollbars, etc. assuming your screen has twice the resolution it actually has. To get a more realistic feel for how things look on a real high dpi monitor, you can adjust your monitor’s built-in display settings to make the picture as small as possible on screen (i.e. squeeze the picture smaller in both the horizontal and vertical directions).
I’ll try to update this post soon with some screenshots illustrating some typical bugs. Most of the Windows common controls (button/scrollbar/trackbar/progress bar, etc.) handle these changes just fine. If you have implemented (or licensed) any custom UI controls, those are great places to look for bugs. Look for things that don’t scale up larger when you enable high dpi. One example I found in Team System was the [X] button on the Folders section of the Source Control Explorer window. The main [X] button on that window scaled fine, as did other [X] buttons on windows like the Solution Explorer, Team Explorer, etc.
For more information (and a professionally written perspective), here’s an MSDN article on developing high DPI applications.
Update: I learned from our splashscreen developers today that if you change your DPI settings after you install Visual Studio, some of the features won’t draw correctly with the new settings unless you start devenv with the /setup command line option. I haven’t yet figured out exactly what all gets reset when you do this, but I did verify that the splashscreen is easier to read after doing this.