Hacker News Reader

Comment by rsync | Hacker News Reader

Can someone explain why this isn't just a continuous dial ?

That is, why are there discreet "steps" in monitor scaling for these elements that you are talking about ? I would think that if I have 157 PPI or 220 PPI or 400 PPI that I would just adjust the dial to fit the element size I want.

What's up ?

View on HN

You can't just take a rasterized image and scale it up or down, the result would look horrible. You need to scale things while they're rendered, and as long as you only do vector graphics like drawing lines and rectangles, that's fine. However, real-world UIs traditionally use lots of bitmap graphics, and those, again, simply can't be reasonably scaled. And PPI scaling even the vector graphics stuff requires major changes to the software and graphics stacks involved, given that historically everybody has simply thought in terms of pixels, not the angular size of screen elements, which is what's actually relevant to the end user.

"You need to scale things while they're rendered, and as long as you only do vector graphics like drawing lines and rectangles, that's fine."

Yes, I'm with you so far ... my confusion is, I thought that is what the "ready for 4k blah blah" improvements in iOS and Mavericks, etc., were.

I thought that was the whole problem they solved, and I am surprised to see it is not. I can see various apps being broken in this way, but the OS elements should all be scalable arbitrarily...

Yeah, I would've also thought that they'd have the issue somewhat tackled by now. OTOH, I suppose it doesn't help much if the OS itself draws itself correctly if the apps are all wonky.

They are. http://arstechnica.com/apple/2007/10/mac-os-x-10-5/10/

This is not a general solution however. Even the new and shiny Final Cut Pro X uses rasters throughout.

There's only three ways to support higher resolution displays:

1. Invest in better tools, like Core UI or PaintCode.

2. Exactly double the density and use @2x resources.

3. Switch to "Flat UI" design language.

For the system UI elements, Apple chose option one. For the 3rd party UI elements, Apple chose option two. For iOS, Apple eventually chose option three.

What about 4: ship the actual Illustrator files used to make those raster resources, and just render+cache them for each size the user actually switches to? (In est, treat them like JITable bytecode.)

GTK on Linux uses Cairo and other vector rendering libraries to draw widgets and icons. You can set the font size or resolution as low or high as you like. This has been true on that system since before 2008 AFAIK.

App developers cannot write code that correctly renders at an arbitrary multiplier. It's been tried and it never works. Having 1x mode and 2x mode does work, which is why Apple uses that approach.

Considering that every 3D game qualifies as an app that renders correctly under arbitrary multipliers, that argument seems a little suspect.

The real answer is that there is an industry of designers accustomed to doing per-pixel tuning of their art assets and this work is worthless if the assets are going to be scaled anyway. Selecting integer multipliers (so far: "2") allows those assets to continue to render as designed on retina displays.

Surely there are aesthetic reasons to prefer this in many cases, but it's not nearly as cut and dry a point as some people tend to think. Most recent Linux desktop themes are using vector assets, for example, with quite good results.

Whether the Mac/iOS world is a community of pixel-exact perfectionist artistes or a bunch of dinosaurs who refuse to use modern tools is a flame war for a different thread.

  The real answer is that there is an industry of designers 
  accustomed to doing per-pixel tuning of their art assets and 
  this work is worthless if the assets are going to be scaled 
  anyway.

That's an effect, but not the cause – the roots of the raster-based paradigm of modern GUIs are far more technical. I would point to the tradeoffs between speed and memory limitations in early GUI systems: If you look at the original Macintosh UI, you'll see a system more constrained by rendering speeds than by RAM, and thus a high emphasis on bitmaps versus vector rendering.

Look at this Folklore.org story on the origin of the roundrect in System 1: http://www.folklore.org/StoryView.py?story=Round_Rects_Are_E... It was only through a combination of Jobs' perfectionism and Atkinson's ingenuity that such a simple thing as rounded rectangles could be accomplished on the original Macintosh; can you imagine how long it would have taken to render a Finder window full of vector icons?

And yet Linux machines have been drawing SVG icons and SVG widgets for years. This limitation doesn't exist any more.

Look at Display Postscript, which was created by NeXT in the late 80s and carries through to much of Apple's Quartz rendering system today. Why are we still limiting ourselves to pixel graphics?

Let's be reasonable... 3D games and traditional desktop environments have a very different set of HCI expectations. You aren't often clicking an icon in a 3D game.

While, I'd probably prefer to have vector graphics for desktop assets just for the flexibility, hand-tuned scaled images usually look better than their vector scaled siblings.

> You aren't often clicking an icon in a 3D game.

Maybe I'm misunderstanding what you're saying. In case I'm not, here are some counterexamples.

Check out the first two pictures in this thread (most things on that UI are clickable):

https://forums.station.sony.com/ps2/index.php?threads/leaked...

Clickable chat UI (Planetside 2):

http://img138.imageshack.us/img138/6746/planetside2201302131...

Clickable UI within a 3D world (Doom 3 had a bunch of these):

http://static.gamespot.com/uploads/scale_super/gamespot/imag...

Despite being told for fucking YEARS to use dialog-box scale units (twips) instead of hard-coding things, pretty much everyone on Windows took the "pragmatic" approach. Can't blame Microsoft for not trying, but they gave up around VB.Net.

Reply on news.ycombinator.com