Daniel Stone recently wrote this amusing summary of why saying OMG I ABSOLUTELY MUST HAVE MY DPI CORRECT is rarely, if ever, correct.
Since most people who say this aren’t considering the two monitor case, I thought I’d provide a illustrative screenshot.
This is an old screenshot of the resolution-independence branch of GTK+ running the demo program on two different monitors. It shows that both apps the physical same size, with the same physical size fonts (ignore the size of the title bars, those are provided by Metacity, which is using the system GTK+).
However, the font rendering looks different. This is because of the amount of anti-aliasing that goes into making fonts look smooth when you have less pixels to play with. Notice how in the title bars the font looks the same, even though they’re different sizes. That’s because they’re using the same number of pixels, and thus the same amount of anti-aliasing.
I couldn’t find a screenshot of what happens when you have a window that crosses between two monitors. [Perhaps it’s a nonsense case, but it can come up.] At this point everything just looks like crap. We have to choose the scaling of one monitor or the other. It will look wrong on one monitor or the other. It will be a different size to everything else on that monitor. [Before you suggest it; we can’t divide the window and calculate the scaling separately for each monitor across single widgets].
The thing is, for day to day computing, you don’t really care about the DPI, you care about having readable, attractive fonts and visible, clickable icons. So Federico is right. For some specific applications, you do care about DPI, but those applications can already use the XRandR data to take care of themselves [I have written visualisation apps which do this, presenting a scale on the screen of millimetres on screen to metres in the real world. ((And in using these apps, I’ve found plenty of monitors that return nonsense DPIs, forcing me to hardcode the monitor size in X11.))]
This said, I’m not sure why the only font size settings now in GNOME is a quantised Small, Normal, Large, Larger setting in the Universal Access settings pane. gnome-tweak-tool includes a scaling slider. The slider is hard to use though, especially when your text reflows while using it. Federico’s idea seems better.
As DPI continues to increase, it’s probably worth also applying scaling factors to our scalable window graphics, lest icons and the like become increasingly harder to hit. At this point we will likely need to adopt a resolution independent GTK+. However, again what will matter will be readable fonts and visible icons. Using the actual monitor DPIs will likely not be that important.
Mac OS X seems to be just going with a 1X regular or 2X “HiDPI” size for resolution independence, same as iOS with the higher resolution “retina” displays. This has the benefit of making the math nice and easy, and stuff that’s rendered high-res and shown low-res in a mixed environment doesn’t look too awful. 🙂 Handling icons and, well, everything else is pretty vital when you’re going with displays that much denser… we’ve got them already on phones (Android phones are hitting the same resolution as the Retina display now with the Galaxy Nexus) and it’s only a matter of time before they read tablets and laptops… would love for the GNOME world to be ready for this too!
On embedded devices things are a little easier. We can ensure the DPI is set right, and then choose fonts and icons that work nicely at that DPI. Embedded devices have custom themes, typically a pixmap theme, where the art is again designed, and is pixel perfect for the specific device.
It’s the PC world where things are a mess. Where you can have a 96dpi 1600×1200 screen and a 140dpi laptop screen and you want a generic look and feel that’s workable on both devices.
Daniel Stone asks his reader to yell at the developers of applications like GIMP to use display size information. Just to let you know, GIMP has support for using the native resolution and and taking that into account when displaying images since version 1.0 or perhaps even before. It’s simply not used by default as many use cases need a pixel-perfect display. But you can turn it on on a per-view-basis (turn off View->Dot for Dot) and you can configure the default behavior for new views in the Preferences dialog.
@Sven: yeah, the only time I find myself caring about dots-per-inch in GIMP is when I wonder do I have enough pixels to print this? And then what I do is stare at the dialog that tells me how big the image is at such-and-such DPI.
I’m sure some designers do need accurate size representation. Although I’ve never been convinced it’s that common (given how poorly screens report their sizes). In visualisation people cared about it, but mostly when printing, so that the scales on their hardcopy graphs would be accurate. On screen most people will use the measuring tool.
You don’t really need resolution-independent GTK+. Don’t search for an exact solution when a simple and suitable inexact one exists.
I am talking about scaling icons together with fonts, but only approximately. We can do this in some steps, because virtually any icon exists in some pre-rendered sizes such as 22×22, 32×32 and 48×48. Just make sure that the same slider (or whatever widget) that controls the system font size also selects the chosen icon size.
@Alexander: that’s one solution. Continuing to add bigger icon sizes.
There are a few other bits that need tweaking though, like rendered clickables such as checkbuttons, radiobuttons, grab-handles on sliders etc., that you begin to need a more generic solution for make my whole UI bigger. To some extent things like this can be controlled by theming, but it’s nice if they can just scale up using a similar metric to the fonts and icons. At this point we want to begin adding the ideas that appear in the resolution-independent GTK+ branch, but perhaps without reference to DPI.
Wouldn’t be svg perfect for icons? The scaling would be lossless and the technique available.
and as far I know you can even implement movements.