Hacker News Reader

Comment by otterley | Hacker News Reader

I don't know a whole lot about GUI programming, but how come resolution independence never took off? For example, "make this element some proportion of the screen width/height", "make this element exactly N cm/mm/inches/pica wide/high".

View on HN

It wasn't made that way in the first place. Remember Windows (which came out in 1985 or so) was designed to run at something like 640x350 with 4-bit graphics on an 8086. Windows 95 was ten years later and only required a 640x480 screen. Bitmapped graphics, supporting things from 16 color to 24-bit color. Check out the BMP file format sometime.

Contrast to something like NeXTStep, which evolved into OS X, started out with display hardware of 1120×832 (although grayscale). More importantly it used display postscript which is vector-based. Even though it came out in 1989 which was only 4 years after Windows 1.0, the computers that ran it were much, much more powerful than the PC of the time. The original NeXT computer was closer in performance to what a mid-range Windows 95 machine was (486DX/25MHz, 8MB RAM, 1024x768 graphics...)

Windows UI was supposed to be in "DIPs" since at least Win32.

http://msdn.microsoft.com/en-us/library/windows/desktop/ff68...

I guess the problem is that when 1 DIP = 1 pixel for almost everybody in almost every case you don't notice when you mix them up.

It means everything in your UI pretty much has to be vectors, which is certainly possible (it's done in games) but UI designers and the tools they use generally aren't used to working that way. Many UI elements would have non-integer thickness and thus would either look blurry due to antialiasing or lumpy due to pixel fitting. And you'd have to deprecate pretty much all of the existing pixel-based APIs and then wait 10-20 years for apps to migrate off them.

On super high-resolution displays, would it really be that bad? I can't imagine rounding errors being that significant on a Retina-quality display. In fact, it was never a problem on 300DPI laser rendering back when I worked in the publishing world.

Am I mistaken?

We don't have super-high-resolution displays. A small percentage of users have moderately high resolution "retina" displays and everyone else has low res. One major benefit of the pixel-based 2x design workflow is that it produces good results on old low-res screens that are still in the majority.

To some degree I think you're correct, but until there are only retina displays on the market we need a solution that works well for both. Everyone looks forward to the day when designing a font doesn't mean spending half your time hinting for those pesky ~85ppi displays, but we're off to a pretty slow start. The first real step in my opinion is to bring real vector support to the web (now that it's reasonably well supported across browsers) but that requires designers to adjust their workflow (and preferably own their own retina displays to test with).

We won't have to make fonts for Retina - we already did, they're (usually) designed to be printed which is much higher DPI than a Retina display.. It wasn't until Windows XP when Microsoft said "Let's make fonts that look great on the screen, at low resolution"

Yes, that was my point (except it wasn't just XP– hinting was/is a PITA on any platform). These days we still have to make them look as good as possible on both, but if you're also targeting printed media then you're already set when high PPI displays are the norm.

WPF went that route by using vector graphics everywhere. It has the nice property that it scales fine, but often you can see small one-pixel jumps of elements, e.g. the thumb in a scrollbar or on sliders. This wouldn't matter at all on a 300-dpi screen but with 96 dpi it's visible and sometimes jarring.

I don't know mich about windows GUI, but from my user experience I think it's just hard (lots of things to consider).

I guess you have to deal with font sizes (handled by the system) you're own contraints ("this button is half this screen", "this screen is at most 800px" etc), and the user scaling your UI.

Before scaling was even an issue, I've seen a lot of app screwing the font and UI size pairing when launched on non english languages with different default fonts settings or wildly longer text(the app's own translated text that is). Throwing in a "what dpi is my screen?" variable to the equation must make things that much harder.

Maybe because it is not a silver bullet? The viewing pleasure of 2cm on my phone != 2cm on my 52inch LCD monitor from 2-3 metres away. Not that I have a 52inch monitor

That's why I mentioned relative dimensions as well as absolute ones.

Reply on news.ycombinator.com