USER & GDI Compat, part 3 -- High dpi

Pixel sizes have been roughly constant for a long time, but LCD manufacturers are increasingly coming out with monitors with smaller and smaller pixels, aka high dots per inch (dpi).  If an application uses the same number of pixels on a high dpi screen as it does on a standard 96 dpi screen, the application will look really small.  Windows Vista introduces the ability to scale applications that were written for 96 dpi screens, which it does by rendering the application’s bitmap at a larger size.  Like all bitmap scaling, this can result in some blurriness, but otherwise gives a correctly size and properly rendered image.  Applications can also decide to support high dpi natively, which will give the crispest possible look.  Currently an application can turn off scaling & declare itself dpi-aware by calling SetProcessDPIAware(); we’re looking to add a manifest-based way to declare this as well.  For more information about writing applications that natively support high dpi, see https://msdn.microsoft.com/en-us/library/ms969894.aspx (coincidentally written by me in a former life).

The rest of this section talks about potential problems with non-DPI aware applications.  Applications ask Windows questions like "how many pixels wide is a scrollbar", so when a 96 dpi application asks, Windows Vista lies and gives the application the 96 dpi answer.  There are however cases where Windows doesn’t lie, sometimes because Windows Vista hasn't learned the right lie yet (please give us this feedback), and sometimes because the “right” answer depends what the application is trying to do with the answer.  (Screen coordinates often raise this problem)

Most compatibility problems come from these imperfect lies.  Things to look for when testing:

• Text is clipped (partially hidden)
• Text is too big
• Something is drawn at the wrong size or in the wrong place

[update 6/4/2008 -- fixed hyperlink to the high dpi paper]