Resolution indpendence

Glynn Clements glynn at gclements.plus.com
Mon Jun 30 16:25:08 PDT 2008


Steven J Newbury wrote:

> > To make 1280x1024 at 120dpi look exactly like 1024x768 at 96dpi, just with
> > higher-quality, you would need to either provide another version of
> > every icon, or you would have to tolerate rescaled icons.
> 
> Every version of Windows from Windows95 (I think) had a set of high
> resolution (large) icons for this very reason.

Windows' icon sizes are: 16x16, 24x24, 32x32, 48x48. The first two are
"small" icons for use in "list" and "detail" views, the last two are
"large" icons for "icon" view, desktop, start menu etc. In each case,
the larger version is 50% larger than the smaller version, whereas the
difference between 1024x768 and 1280x960 is 25%. It's not like fonts,
where they typically provide bitmaps at 2pt increments.

> > If the original icons are 16x16 pixels, the higher resolution versions
> > need to be 20x21.33. And what you do about the extra 0.33 pixel is far
> > from straightforward.
> 
> Going forward with SVG icons it's not going to be a problem.  A "best" (user 
> preference) solution can be applied for "legacy" software if necessary.
> Notice that Vista deals with all legacy applications by using the hardware
> scaler of the graphics card to provide 96dpi compatiblity.

This only really works for larger icons. If you have a 48x48 icon,
anti-aliased re-scaling is likely to give adequate results at "large"
icon sizes. When you get down to the 16x16 icons used in the file
manager in list/detail view, it really needs to be hand-tuned to avoid
just being a coloured blob.

> > The interface between software components needs to be rigid, but the
> > interface between the computer and a human less so. Users are normally
> > asking for more DWIM, not less.
> > 
> > [Much of the time, it's because they don't really understand the
> > consequences of what they're asking for, and wouldn't like it if they
> > got it. But that's not always the case.]
> 
> I'm not sold on this.  Computers currently lack sufficient context and
> intelligence to achieve DWIM in any way that doesn't really annoy a very
> large proportion of the userbase.  Until we get to AI, I think computers
> should do as they're told and respond in a predictable manner.

I don't much like DWIM either, but then I'm a programmer. I'm used to
analysing exactly what I'm trying to achieve, and to figuring out how
to achieve it. User's often don't know in concrete terms what they
want, but they know if it's not right and, to an extent, why.

AI won't make it any better. If you want predictability, true AI will
make it even worse.

Really, it depends upon the situation. DWIM is a bad idea for discrete
choices, and where getting it right matters. OTOH, where you have a
continuous range, and you only need to be close enough, it can save
the user from wasting time micromanaging stuff they don't particularly
care about.

> > > This just makes no sense.  If the true DPI is 220 on a decent size
> > > screen, text at 12pt will be unreadable by most if the system DPI is
> > > fixed to 96!  It will only give the expected (readable) result by either
> > > setting a lower screen resolution or by using the true DPI to render the
> > > text!
> > 
> > If the true resolution is 220 dpi, you will likely get the best
> > overall results by pretending that it's 192 dpi, i.e. *exactly* twice
> > 96 dpi[1]. The difference between 192 and 220 is just under 15%, which
> > is noticable but not critical, but you can then rescale everything by
> > exactly 2:1.
> 
> Perhaps you should tell the hardware manufacturers?

Why? There's no reason for the hardware to actually be 192 dpi.

The 96 dpi figure was just an arbitrary value, chosen so that various
common point sizes (6, 8, 12, 16) would work out to an integer number
of pixels.

> > Fonts actually get rendered at twice the resolution (or, if you have a
> > hand-tuned bitmap designed for 24pt @ 96dpi, you would use the same
> > bitmap for 12pt @ 192dpi), while icons just have every pixel drawn as
> > a 2x2 pixel square. No blurring, no jaggies.
> 
> Or you could use outline fonts and vector graphics for icons rendered
> with sub-pixel anti-aliasing.  Little perceivable blurring, full
> resolution and correct scaling.  It would be interesting to see which
> looked better...

I already know the answer to that. At least, *my* answer. Whenever I'm
confronted by grey pixels, my first action is to figure out how to
make it use a bitmap.

If the resolution is low enough that you notice the jaggies on non-AA
outline fonts, a hand-tuned bitmap will win out over filtering every
time. Actually, even tolerating the jaggies may win out over AA.

> > The end result is likely to be a lot nicer than if you insist on
> > treating point sizes as sacrosanct, scaling everything by exactly
> > 2.291666:1 (220:96).
> 
> I'm not convinced.

I don't doubt it.

> You'll have to try harder.

What's the point? It's not as if any amount of argument is going to
convince you. "For your friends, no explanation is necessary; for your
enemies, none will suffice".

-- 
Glynn Clements <glynn at gclements.plus.com>



More information about the xorg mailing list