High DPI makes for high bugs

I’m in the middle of shifting jobs. I said so long to the wonderful Lenovo Thinkpad with only a 1024×768 display and I bought myself a nice Dell Latitude D820 with a 1920×1200 (WUXGA) display. I know my productivity is tied somewhat to number of pixels at my disposal. If I run out of room on my display for developer tools, I’m far less efficient than I could be. There were features I love that I didn’t use on the 1024×768 display.

When I first started up the laptop I thought “Oh NO! These are not my eyes from when I was 16 years old!” I was afraid I had made a terrible mistake. I was slouching trying to read the display. I stepped through the new computer configuration and I immediately set the DPI from the default 96 DPI to the “Larger scale” setting of 120 DPI. This helped. Later that day or the next I did something I almost never do. I was using The Gimp to manipulate some image and I was using its inches support. I decided that it may be good if the inches scales actually were sized correctly. I figured having the correct DPI setting in your OS can only be good. Print Preview should be most accurate that way. I talked to some people who know displays far better than I do (#Linux from arstechica).

It turns out that my display has a 148 DPI (15.4″ diagonal – 1920×1600 – do some math). Windows confirmed when I pulled out a ruler and adjusted the numbers using the “Custom scale” setting. I was happy that this custom scale UI existed and I was even more happy that it visually confirmed what the calculations said. Once I set to 148DPI things were great. Fonts were huge.

By that I mean that fonts were the size they were supposed to be, but I have great vision. I can read Consolas at 6pt and I regularly run it at 7pt. Some things were just too big. Title bars and menus seemed like they were wasting screen real estate. As pointed out the day of the Safari release, Safari doesn’t use ClearType in Windows. Apple does their own font rendering (I’m guessing) in Safari for Windows. As a results my DPI settings had no effect on the display of fonts in Safari. So for a couple of weeks I ran with Safari being too small, and many things in windows being too big.

I’ve since reset my putty to default to 7pt Consolas instead of 8pt and today I shrunk the font from 9pt to 8pt for pretty much everything I could find in the Advanced Appearance dialog (it is still there in Vista).

Advanced Appearance

This is my most usable configuration yet. I love it.

I am disappointed with certain things which do not work with this high DPI setting. Windows Media Player for example seems to break some UI design guidelines. Ya know, the ones that basically say “use relative positioning so your application will work with various font sizes, DPI, and display resolutions, oh and this also means it will be easier to internationalize because that text that is four short words in English takes up 100 pixels, but it takes eleven long words in Finish, but only two Kanji in Japanese.

Leo Laporte - The Tech Guy 347 - Windows Media Player

See how the fonts are overlapping in the right top pane. Shame on you Microsoft.

Windows Media Player really surprised me by its little quirk. I was less surprised with the bug in Windows Live Writer. During setup for a new blog, it asks a couple of questions in a wizard.

Windows Live Writer

I couldn’t click the third option, yet it was the one I wanted. Luckily I could use the keyboard, tab, tab, tab, enter.

Windows Live Writer (2)

What you cannot even see on this screenshot is that there are two textboxes for username and password. I had done this wizard once before. When the next step said invalid username and password, I guessed that I had forgotten it on the last step. Again keyboard to the rescue, tab foo, tab bar, enter.

The really interesting thing here is that I’ve NEVER had these kinds of issues with either GNOME or KDE in Linux. I’m not a holy war kind of guy. I like both Windows and Linux. I use both Windows and Linux, but it seems to me that the Linux guys figured out the best practices for this type of layout a long time ago and they tend to use them. It is no coincidence that when you open Visual Studio you still get a grid on which to put controls in a fixed position. Yet if you open GLADE or QtDesigner the default is a Container that is NOT the fixed layout container.

4 thoughts on “High DPI makes for high bugs”

  1. $10 says those same windows devs would find the fixed layout stuff in glade or qtdesigner 😉

    Bad coders will write bad code no matter what system you put them on – the tools for flowing layouts are readily available in Visual Studio, they just have to be used 🙂

  2. FWIW, I have seen those kinds of errors in GNOME. For some reason right now, one of my GNOME file chooser windows shows all of two, yes 2, file choices, and the brillant (sic) developer that designed this file chooser chose to make it not resizeable. Very annoying.

    Glad you like the new lappy.

    Good luck, and much love.

    e.

  3. I’m one of the devs on the Writer team. Interestingly, its really when you go to doing programmatic UI that you get burned. In general, in High DPI, Windows automatically scales controls and positions of controls even on drag and drop forms. It actually works pretty well in most cases, so long as anchoring and what not is set correctly.

    In the case of our wizard, we’re dynamically adding and removing panels, and this causes issues for us since we need to explicitly manage the scaling. I thought we had those issues licked, but perhaps not. Are you running Beta 2 of Windows Live Writer (just released a few weeks ago)? I’ll double check that we’re handling scaling of this UI correctly so we have this fixed in an upcoming release…

    Sorry that you ran into this!

    -charles

  4. Charles,

    Yes, this was Live Writer Beta 2. Which, by the way, I used to post this post. I love it. It is awesome. My only complaint is with the setup wizard. Thanks for this awesome software.

Comments are closed.