Avalon, high DPI and screen real estate


Today, beloved readers, I will weave a story of powerful forces in conflict with each other through time, and how Avalon saves the day...

As time goes by, screens are getting better resolution for the same physical size. This means we get smaller content, and more "room" to put that content in. My home LCD runs at 1280x1024, and that's not the largest I've seen by far.

More screen real estate, more content that is visible at the same time, happy users (unless they can't read the small font).

What we generally have is more pixels in the same space, or in other words, our dots-per-inch have increased. Enter high DPI.

Normally, Windows runs in 96 dots-per-inch, so a high resolution means small content. However, you can ask the OS to run at a higher DPI setting.

You do this by changing the value from the dialog that pops up when you press the Advanced button of the Settings tab of the Display Properties dialog, which in turn you can invoke by right-clicking on the desktop and selecting Properties. Admittedly, I've changed this value once in two years, so I can't complain of it being out of the way. 🙂

Back to our scheduled story. Setting a higher DPI value is a step in the opposite direction from hardware advanced - things are bigger now, so you can fit less content on your screen at once.

I encourage you to try this right now on your machine if you have a good LCD display. I'll wait.

Combined with ClearType technology, the results are gorgeous. The content is sized bigger, but the curves in fonts and other content take advantage of all the teeny tiny pixels to draw a path that is much more pleasant to the eye.

Avalon now allows developers to very easily create scalable content that looks good at any physical resolution. This is done by introducing resolution-independent and device-independent graphics together with the strong emphasis on vectors.

My own, wild, personal bet, is that users will use higher DPI settings when they see how great it looks, and that yes, developers will still need to make smart choices about how they allocate screen real state in their application to get the best results.

So it looks like better resolution will not solve all of problems screen designers face (and what fun would that be?), but instead they will enable end-users to have an awesome experience using their computers. And that, in my book, is goodness.

This posting is provided "AS IS" with no warranties, and confers no rights.


Comments (8)

  1. Looking forward to being able to use high-dpi displays.

    I think Microsoft/Intel even have a spec for boot screens that are readable on high-dpi displays.

    The big bottleneck for most users to doing this today (pre-Avalon) is that Internet Explorer does not honor the desktop DPI settings correctly. (Try it — you’ll find your web page layout is all screwed up, because images are not scaled with the DPI setting, while text is scaled wuth the DPI setting.) So most people who try changing their DPI setting end up reverting to the normal setting just to get IE to render correctly.

    It’s sad — for lack of a few multiplies in the IE code a whole generation of users is unable to use high-DPI displays.

  2. RichB says:

    In the same way, why in WinForms does Scale() get called for higher DPI (when AutoSize=true), but the PictureBox doesn’t automatically stretch any image. It seems an obvious thing to do, and would fix the majority of WinForms apps which, when run on a higher DPI, screw up.

  3. Marcelo says:

    I don’t have an authoritative answer, but that’s not going to stop me from wildly speculating.

    IE does scale text and stuff. I imagine that the web rendering problems and the image rendering problems stem from the fact that some elements are specified in terms of pixels. Therefore, they are not defined in terms of inches, and so dot-per-inch changes do not scale them. Things defined in terms of font points (which is a unit defined in terms of inches) does allow a more flexible display.

    Images are especially tricky to deal with. Pixels can represent hard data, for example in financial charts or maps, and anti-aliasing or scaling these pixels may present incorrect information. Spooky. Plus, without vector information to smooth the paths, scaled images are just plain ugly.

  4. Dean Harding says:

    Re Internet Explorer with high DPI. I ran at 144 DPI on my laptop (it’s a 15.4" screen @ 1920×1024 – impossible to read with 96DPI at the native resolution) so I run into DPI issues all the time, but Internet Explorer (at least version 6, SP2) is great (well, the only issue is that it doesn’t do a smooth scale of the images – they’re quite blocky at times).

    I’ve tried Avalon with a high DPI, but as of the first CTP, there’s too many bugs to make it worth while (menus don’t look right, if you explicitly set the size of a window, the vertical size honours DPI, but horizontal does not, and the list goes on) but my hope is that they’ll be fixed for the next CTP.

    I see high-DPI becoming more of an issue as time goes on, because the resolution of displays will just get higher and higher, even though the physical screen size may not (necessarily – certainly not for laptops). I didn’t try WinForms with VS 2005 yet, but I know there were DPI issues with v1.1 (the PictureBox problem that RichB mentioned – I had to write my own code for displaying images that honoured the DPI, which was a bit annoying).

  5. Piethein Strengholt says:

    Anyone can post a screenshot? I’m very curious!!

  6. Dean Harding says:

    You mean a screenshot of ClearType?

    It doesn’t do it justice at all, because it’ll really only make sense when viewed on an LCD display. This is because of the way LCD works. The pixels on an LCD screen are actually made up of three separate parts: a red pixel, green pixel and blue pixel. So if your monitor is 1920×1024 then there are actually 1920*3 = 5760 pixels horizontally. Your brain just merges them all into one colour.

    ClearType works with the fact the pixels are lined horizontally like that to perform sub-pixel anti-aliasing. That is, when it’s anti-aliasing a line, it’ll use the red component of the pixel to the left and the blue component of the pixel to the right to help smooth the line even more. The results are absolutely gorgeous.

    Anyway, I posted a screen shot at http://www.codeka.com/images/misc/cleartype.png and you can see what I’m talking about, because you’ll notice the left side of all the lines are tinged red and the right side are tinged blue.

    If you also have a higher DPI set, then ClearType works even better because it’s then got even more pixels to smooth the lines.

Skip to main content