Essential XAML

# re: WPF is DPI Dependent

You've rather comprehensively missed the point here:

"Even if you choose to work with "cm" or "in", first you will not get the correct size (measure it!), and second if you change the resolution the size will change also"

*If* your system is correctly configured, you will in fact get exactly the correct size. If you have a 120dpi screen and you configure Windows so that it *knows* you have a 120dpi screen, and you ask WPF to make something 5 inches across, it will be 5 inches across.

Of course, if you change the configured resolution, then unless you also go out and buy yourself a new monitor whose dpi matches the new dpi setting you just configured, the size will change. If you lie to Windows about the dpi of your monitor, then you can't blame WPF for rendering things the wrong size. In order to render things at the correct size,  WPF absolutely needs to know what the DPI of your monitor is.  Without that information, how is it supposed to know how many pixels it needs to render in order to make something a particular size?

The point people often seem to miss is that Windows doesn't magically know how big your screen is. If you disconnect a 17" 1280x1024 monitor and replace it with a 19" 1280x1024 monitor, obviously you now have larger pixels (i.e., a lower dpi), but Windows doesn't know that. It only knows that you've still got a 1280x1024 screen in place.

Sadly, historically there has never been any way for the monitor to notify Windows of its DPI. This is partly because for years we used CRTs, and there's not all that much variation in dpi from one CRT to another. Not compared with printers - printer resolutions range from 100dpi for dot matrix printers up to thousands of dpi for typesetting machines. Since the resolution of printers has always spanned orders of magnitude, they really had to solve the problem properly. The upshot of this is that printers always know *exactly* what their DPI is. But in the world of screens, this never happened, because it wasn't as pressing a problem.

The monitor's VGA cable doesn't have a way of passing dpi information from the monitor back to the computer. And while doubtless DVI and HDMI could do this sort of thing, the problem is now one of inertia - Windows works like it always has. (And this is a problem for Macs too. It used to be a problem only if you fitted a non-Apple monitor, but now the latest PowerBooks come with pixels that are smaller than the Mac thinks they are. So Mac laptops get sizes wrong too.)

So Windows is totally and utterly dependent on that DPI setting - that's the only information it has about how big the physical pixels on your screen are. And if  you lie to it, of course it generates incorrect results.

The worst of it is that people have observed that providing Windows with incorrect DPI information has the side effect of changing how big everything looks, and so the DPI setting has frequently been abused as a sort of 'size control', which really isn't what it's designed for.  This abuse has become so ingrained, that Vista even tells you this is what it does. So it's difficult to see how Microsoft could ever get themselves out of this problem. Nonetheless, WPF uses this DPI setting as it was designed to be used, and not how it is popularly abused.

I think it's compounded by the fact that the dialog suggests that you are changing the DPI of your screen.  You're not - you can't do that. If you want a different DPI you need to get a different screen. The DPI is fixed - its determined by unchangeable physical characteristics of the screen: it's the number of pixels across the screen divided by the width of the screen. For a flat panel, you can't change either of those values.  (For a CRT it's more complex.  The width is fixed, but you might be able to run with a number of different pixel counts. On a given CRT, the DPI at 1024x768 will be lower than at 1280x1024. But for given pixel dimensions, the dpi is fixed, because it is determined by the physical size of the screen.)

The DPI Scaling window doesn't change the DPI of your screen. It changes what Windows *thinks* the DPI of your screen is.

(As an aside, if you're using a projector, then you can change the DPI. The further away the projector is from the screen, the larger the image, and therefore, the lower the DPI. But usual reason for using a projector is to make the display much larger, so an incorrect DPI configuration turns out to be desirable. Otherwise, Windows would attempt to make, say, 16pt text really be 16pt, which would probably amount to 2 or 3 pixels...)

As for this:

"to create a real DPI independent UI, in case that you must display exactly the same amount of pixels, no matter what the DPI is"

*splutter*  No no no! That's the exact opposite of a DPI-independent UI.

Consider what it would mean if what you say were true. Suppose you render a 96 pixel button. If you display that on a screen that happens to have a 96 pixel per inch resolution, it'll be one inch across. If you display 96 pixels on a 600dpi laser printer, it'll be less than one sixth of an inch across.

If your image shrinks to one sixth of its size when the DPI goes up by a factor of six you emphatically do *not* have DPI-independence. The size of a 96-pixel element is totally dependent on the DPI of the device.

DPI independence means that you render things the right size regardless of DPI. So in the case of a 1 inch feature, that means using 96 pixels on a 96dpi screen, 144 pixels on a 144dpi screen, 600 pixels on a 600 dpi laser printer and so on. This is DPI independent because the feature ends up being 1 inch regardless of the DPI of the device.

Of course, you need to *know* the DPI of the device to make that work.

WPF is independent of device DPI in that it is able to render content at the correct size for any device DPI. The problematic part is that WPF depends on the device actually knowing it's own DPI; in Windows, the screen does not know, unless you the user have correctly configured that DPI setting. The vast majority of the time, WPF is working with incorrect information. But given correct information, it behaves correctly.

# re: WPF is DPI Dependent

Keep on posting such stories. I like to read articles like that. By the way add some pics :)

# re: WPF is DPI Dependent

@Ian Griffiths: I've never heard such a load of drivel in all my life.

Windows has been able to determine the physical DPI of a screen since Windows 95 days (some Windows 3.x apps could do it themselves). Even on old CRT monitors, the DDC (Display Data Channel) pins on the VGA connector have been able to deliver EDID (Extended Display IDentification) data to the host computer.

The EDID packet contains the physical height and width of the display area along with all of the resolutions it can display. It is trivial to determine the DPI for any given resolution from that data. Manufacturers who chose not to implement either DDC or EDID could still specify these things in an .INF file for their particular screen.

The WPF team has no excuse for this.