Confusion over what’s commonly referred to as “screen resolution” causes headaches for computer users – literally. People all over the world are having a computing experience that’s nowhere near as good as it could or should be because their displays are wrongly set.
In a comment on my last post, my good online friend Richard Fink said:
I’ve done considerable googling on this, have ingested a White Paper on IE’s new Adaptive Zoom feature, and yet am still largely in the dark.
Will the new Bill Hill please don his mask and cape and shine some light on this? I sure would appreciate it. Because when you say “resolution independent” I have no idea what that truly means, let alone what the ramifications are.
And I know I’m not alone.“
No Richard, you are far from alone…
People normally refer to resolution in terms of the number of pixels horizontally and vertically on the screen; 800 x 600, for example. But what does 800 x 600 really mean?
The term “resolution”, as commonly used, is a misnomer. It’s only a pixel count, and tells you nothing about the actual resolution of that display.
Resolution ought to mean “The level of detail the screen can display”. It ought to be specified as 96 pixels per inch (ppi), or 133ppi, which easily translates to: “Able to resolve detail down to 1/96th of an inch, or 1/133rd of an inch”.
An 800 x 600 desktop display with a 17” screen would be pretty low-resolution – less than 60 pixels per inch. But an 800 x 600 mobile phone, with 3-inch display, would be really high resolution – 333ppi.
Usually, when you buy a display, the specification will almost never mention ppi; instead, manufacturers refer to dot-pitch, measured in millimeters. In my 133ppi example, the 1920×1200 on a 17-inch display, you would get a dot-pitch of .19 mm. ( But Apple is the exception – as usual – and markets the “high-resolution 133ppi screen” of the 17-inch MacBook Pro as a feature).
In some contexts, manufacturers use the term megapixels, which would be either .7 MP for 1024 x 768 or 2.4 MP, if you include subpixels. It is more common to see megapixels referring to digital cameras – but it is sometimes used for displays.
Mostly, though, people quote only the “pixel count” – e.g. 1024 x 768 – which tells you nothing about the level of detail your screen can display, since it ignores screen size or pixel size. To know the resolution of your display, you need to know both the pixel count and one or other of those numbers.
This is not just semantics. Because these “pixel counts” have become standards, people use them all the time as measures of “resolution” – and that’s only true if you’re always comparing the same size of display.
This “resolution misnomer” affects millions of computer users. As a result of the confusion it has caused, only a minority of computer users are actually reaping the benefits of higher-resolution displays they bought. In most cases, they end up using them at lower resolution – inadvertently turning what should be a really great, crisp visual experience into an awful one. And they get more eye fatigue than they should.
How did this happen?
In the beginning was the CRT – the Cathode Ray Tube monitor, that hulking great brute of a box that used to sit on your desk.
The CRT monitor began life as just another TV. It had no such thing as a “pixel”. The inside of the screen was covered with an amorphous layer of phosphors, which glowed when hit by a beam of electrons from a rapid-scanning “electron gun”. In order for the software running the computer to be able to address these phosphors, a “virtual” or “logical” pixel grid was created.
The “resolution” of this grid was dependent on:
- The accuracy and tightness of the electron beam, and the granularity of the phosphors (usually determined by how much you were willing to pay for your display)
- The number of “virtual pixels” your graphics card could manipulate per second (again, normally determined by cost).
Let’s be absolutely clear: In the CRT world, there was never such a thing as a true pixel. Even when Sony came out with its Trinitron aperture grill displays, which had Red, Green and Blue phosphor areas aligned horizontally side-by-side, these did not behave in exactly the same way as the pixels on today’s Liquid Crystal Displays (LCDs).
Since phosphors “glow” when hit by the beam, there is always some “bleeding” of light to adjacent phosphors. This could actually benefit the user, especially when displaying text. Think of it as free anti-aliasing. Also the analog signal often led to mis-targeting.
Some history can explain what happened…
In 1981, IBM introduced its first color graphics card, which it named CGA (Color Graphics Adapter) It could address 640×200 logical “pixels”, and the highest color depth supported was 4-bit (16 colors). To keep the “Television” aspect ratio of the screen (4:3), the pixels were elongated, or non-square.
In 1984, IBM introduced a new EGA (Enhanced Graphics Adapter), which produced a display of 16 simultaneous colors from a palette of 64, and addressed up to 640×350 logical “pixels”.
In 1987, with the IBM PS/2 line of computers, IBM introduced the Video Graphics Array (VGA), able to address 640×480 “pixels”. (I keep putting pixels in quotes because it’s important to keep remembering that there were no “real” pixels in these displays, only logical ones…)
These “logical pixel counts” became standards. Other manufacturers cloned them. As new graphics cards came out, the figures went up – to 800 x 600, then 1024 x 768, 1280 x 1024, and so on. (Recognize those numbers?) And those standard configurations became referred to as “resolutions”, even though the term was a misnomer.
In the meantime, a new class of displays had appeared using Liquid Crystal technology. At first, these LCDs were black-on-white (in reality, dark gray on lighter gray), but by 1988 they had reached VGA resolution (Compaq SLT 286), and 256-color screens by 1993 (PowerBook 165c), progressing quickly to millions of colors and high resolutions.
And that was where it all went wrong. Manufacturers built them to the same standard “resolutions” (really, pixel counts – 1024 x 768, and so on) – because they wanted them to run on existing graphics cards.
The real tragedy for users was that computer operating systems treated them exactly like the CRTs they were replacing – as if their pixels were still only logical (and thus changeable). But they weren’t…
The wiring track emits no light, so there’s little bleed between adjacent sub-pixels. And because these pixels exist in the hardware and are not merely logical, each LCD display has its own native resolution.
Native Resolution: The actual number of physical pixels in the hardware of a display. (Again, it’s a bit of misnomer, since it’s only a pixel count and tells you nothing about pixel size or screen size).
If you address your display at anything else but native resolution, though, you’re asking for trouble.
On a CRT, since the pixels are logical-only, you could change the “resolution” either in software, or by changing your graphics card. It didn’t matter – it was just another “virtual pixel grid” for the system to compute.
But if your LCD display is, say, 1920 x 1200 pixels (like the 17” display on this MacBook Pro), the number corresponds exactly to a grid of real physical dots hard-wired into the display. It’s inherent in the hardware, and it can’t be changed by software. There really are 1920 pixels across my screen, and 1200 down. Each pixel needs to be addressed exactly. The true resolution of this display is 1/133rd of an inch, because there are 133 pixels per inch.
However, when people launched their new high-resolution displays with Windows, for example, they often found that the icons, menus, etc were too small to read comfortably. Again, there’s a cost associated with this – it’s like having to strain to read the “small print” on a document.
Unfortunately, there’s a very easy – but very wrong – way to fix this. If you don’t know what you’re doing, you go into Display Settings, and change your display “resolution” from 1920 x 1200 pixels to, say, the recognizable old favorite of 1024 x 768.
Your icons and text get bigger. But it’s a usability disaster. Your display is no longer running at its native resolution. Instead of 133ppi, you’re getting only 70.93*ppi. Everything has to be scaled, because there’s no longer 1:1 mapping between the pixel addresses your software calculates, and the actual digital addresses of the physical pixels. That means lots of rounding and fudging of the numbers.
Look at the math involved. 70.93 is a repeater – a horrible number to deal with in this context. Instead of clean, integer-only calculations, now software calculations have to be rounded to the nearest whole pixel. Scaling errors appear all over the place. Bitmap graphics become pixellated. Unlike bitmap graphics, fonts are scalable. But Cleartype – which is dependent on exact sub-pixel addressing – breaks horribly. And so on.
You get the larger menus and icons you wanted – but the cost to your eyes is terrible.
There is a second way to fix this, which you sometimes see: create the lower-pixel-count version by using fewer pixels on the screen, leaving a black frame of unused pixels around the outside. However, people feel cheated with this technique, even though it avoids scaling problems. Arguably, this would be a better solution when reducing the display resolution to match a screen projector.
The overall cost of this misunderstanding about resolution is enormous. Only a minority of computer users with high-resolution displays actually run them at native resolution. And the problems this causes are a major reason why high-resolution displays have never taken off in the way they should have.
If you know what you’re doing, you can fix this properly. First you make sure your screen is running at its native resolution, then go into Display Properties (in Windows XP) or Personalize (in Vista) and use the DPI Scaling dialog to set the Scaling (for fonts) to the real ppi of your display – instead of changing the “resolution”.
Seven years ago, I had a 22” desktop LCD display (IBM T221) that handled a true 204ppi. (3840 x 2400 pixels!!!!) In those days, I had to jump through many hoops to get it to work properly. You could get it to work after a lot of tweaking of things like icon sizes, spacing between icons etc., in the Display properties/Appearance dialog. But it was a lot more trouble than any regular user would wish to take.
The real problem, though, was insurmountable. In most software, websites, line-of-business applications and so on, dimensions of graphics, dialog boxes, text windows etc. had all been specified in pixels.
Windows, most of the applications which run on it – and the Web – were built on the assumption that all displays were ~96ppi. That was true for a while – but no longer. And there’s a threshold – I think it’s somewhere around 133ppi – where software and sites built on that assumption start to break, horribly…
A bitmap graphic which was created on a 96ppi display is less than a quarter of that size when viewed on a 204ppi display (half as big in each dimension). Even worse: If dialog boxes have been created using pixel dimensions, the area provided for text is only a quarter of the size but if the text scales properly it overflows, often clipping. It’s a real mess!
My good friend Chris Wilson on the Internet Explorer team created a workaround many years ago to run IE on really high-res displays. Instead of 96ppi, he created a switch which assumed 192ppi – and then every pixel was doubled. It wasn’t perfect, but it worked – and it still works today.
One bright spot in all of this mayhem was Microsoft Office. Starting with Office 2003, the team made Office resolution-independent. Word, PowerPoint, Excel, Publisher, Visio – all the Office applications have run like a dream on higher-resolution displays ever since. I have highlighted this in the past, but I’m glad to do it again, because I can never thank Office enough for grasping the nettle early, doing the right thing – and blazing a trail for others. If complex applications like these can be made resolution-independent, there’s really no excuse for anyone else.
Over recent years, Windows has been getting better about this (and I know Windows7 is another step in the improvements). At one time, Windows also assumed ~96ppi. Greg Hitchcock of the ClearType and Readability Research team at Microsoft wrote a great blog entry about this.
You’ll see from the DPI Scaling dialog that there’s now a 120dpi option as well. In addition, you can use the Custom Scaling option at the bottom of the dialog box to set Font DPI to the actual ppi of your display. But that can cause problems, too, and on this 133ppi display I’ve fallen back to 120dpi for Font Scaling.
So here’s what you do:
- If you’re running an LCD display, make sure you set Windows to the native resolution of that display. Then use the Font Scaling dialog to set Font DPI to 120. There’s no point in setting your Pixel count higher than native, either, even if your graphics card supports it. You can’t create new hardware pixels using software. (Although, with ClearType, we found a way to use three times as many in the critical X-axis by addressing the RGB sub-pixels separately for text, instead of the whole pixel triad).
- If you’re building software or a Website, make it resolution-independent by never using pixel dimensions. You can use percentages for dimensions like margins, point sizes for text (which the software will translate into the correct number of pixels if DPI Scaling is set correctly).
- It will take a very long time for this to work its way into common practice. But it needs to happen, and you can make your applications and sites future-proof if you do it now.
I’d like to thank Greg Hitchcock and Richard Fink, who both proof-read this article, clarified some technical issues, and made helpful comments.
A Microsoft Word .doc version of this post is now available on my website.