OS X Lion's HiDPI Modes Lay Groundwork for Retina Monitors

[err404]

This is why Apple uses multiple graphics at set sizes. It doesn't explain why those graphics at set sizes are not vectors (which, I agree, would be an improvement, albeit at runtime performance cost), but it definitely explains why vector graphics alone do not solve the scaling problem.

This is the key point. No single solution will answer all of the issues with scaling UI elements. A robust solution will allow for various graphic types (Bitmap, Vector, Procedural, etc...). Rendering each element once at run time and storing the cached image will resolve any performance hit.
jettredmont also makes a good point about detail in scaled images. Uniformly scaling an image is not sufficient. Key image elements may not be determinable at some scales. Variants of the image are required depending upon scale.

 

[jettredmont]

Yes. Loading a bitmap into texture memory based on a context is far faster than loading a vector and then rendering it out to the correct size in real-time. Perhaps this will be a negligible performance hit in 10 years, but right now, 50 bitmaps vs 1 vector that needs to be re-rendered is always going to be better.

Interface elements only need to be "rendered" the first time they are displayed in a particular scaling ratio. I'm fairly certain Apple could devise an intelligent caching system for this. At that point, other than perhaps the second after the screen resolution scaling is changed, performance is identical to bitmaps because you are just dealing with bitmaps to use as textures.

IMHO, I think it is far more about giving a designer multiple static targets to draw to instead of asking them to draw in vectors which might interact poorly as they scale. That and inertia.

 

[err404]

In the end I would much rather the go the iP4 route and just get it done and actually be using a high DPI monitor next year. Instead of waiting 5 years for a vector overhaul to the OS that in the end the results to me (end user) will be much the same on a high DPI monitor.

Why are these exclusive? Roll the pixel doubled solution now but also lay the frame work for resolution independence in 5 years...
I would love to be able to scale my desktop windows smaller to fit more information and then scale them larger for some casual browsing. Today's solutions don't easily allow this.

 

[jettredmont]

3) You note that lots of designers save things as vectors, but as noted elsewhere, why save out a 16x16 icon, a 48x48 icon, a 64x64 icon, a 128x128 icon… instead of just one vector graphic?

Well, that would need to be 4 vector graphics (isn't there a 32x32 usually as well? and I think you also have 256x256 and 512x512 to output as well). Maybe 2-3 if you were skimpy / ready to settle for kind of cartoony display. One vector graphic won't scale well across a more than, say, 2-3x (linear) scale factor.

Generally speaking, in my experience, interface icons do start out as vector graphics, which have multiple "complexity" reduced versions for small-size output. They are then rasterized to bitmaps, and the bitmaps are further polished to ensure they look completely "right".

As far as MOST UI graphics, though, I don't think we need to worry about a 32x scaling factor. More likely we are dealing with scaling in the 1x-4x range for all conceivable screen resolutions (once the screen resolution is greater than can be perceived by the eye, what is the point of going further? That is a "fuzzy" boundary, but it is real nonetheless!)

 

[err404]

Well, that would need to be 4 vector graphics (isn't there a 32x32 usually as well? and I think you also have 256x256 and 512x512 to output as well). Maybe 2-3 if you were skimpy / ready to settle for kind of cartoony display. One vector graphic won't scale well across a more than, say, 2-3x (linear) scale factor.

Generally speaking, in my experience, interface icons do start out as vector graphics, which have multiple "complexity" reduced versions for small-size output. They are then rasterized to bitmaps, and the bitmaps are further polished to ensure they look completely "right".

As far as MOST UI graphics, though, I don't think we need to worry about a 32x scaling factor. More likely we are dealing with scaling in the 1x-4x range for all conceivable screen resolutions (once the screen resolution is greater than can be perceived by the eye, what is the point of going further? That is a "fuzzy" boundary, but it is real nonetheless!)

Let's assume that the UI element will be 1/4". The physical size largely determines the appropriate vector LOD and somewhat eases the complexity of requiring multiple version. For the vast majority of your UI, you should need at most 2 variations (one very simple for low DPI and a regular one for mid-hi DPI).
As for Dock-like icons; why reinvent the wheel? That problem has already been addressed through bitmaps. Large complex elements will frequently look better as bitmaps. Why waste time with vectors?

 

[jettredmont]

Apple Logo 16x16:
SVG: 16 vector points. 3 color swatches. 1 gradient. 95 KB (uncompressed SVG format).
PNG: 256 pixels. 32 bits per pixel (8 bits per RGB + alpha channel). 78 KB (compressed format, 82 KB uncompressed)

Apple Logo 32x32:
SVG: (same file)
PNG: 1024 pixels. still 78 KB (compressed format, 94 KB uncompressed)

Apple Logo 128x128:
SVG (same file): 95 KB
PNG: 16,348 pixels. 92 KB (compressed format, 156 KB uncompressed)

Apple Logo 512x512:
SVG (same file again): 95 KB
PNG: ~262K pixels. 127 KB (compressed format, 945 KB uncompressed)

Apple Logo 1024x1024:
SVG (same file again): 95 KB
~1 million pixels. 168 KB (compressed format, over 3.4 MB uncompressed)

I guess I don't see the advantage in using pixel formats for simple UI elements at any resolution.

I think you just proved the opposite. You took one of the simplest graphics, and found that the bitmap only becomes larger than the SVG when that graphic is 512x512?

Add in more complex gradients and shapes, and a need to add/remove complexity as the scale increases/decreases, and the SVG side of the comparison really starts to look like less of a winner!

Again, though, I really don't think the problem here is file size or even rendering time. File size is cheap to account for (and if Apple used something more purpose-designed than SVG here they could save significantly, I believe), and render time is easily made negligible by caching (further file space requirements though). I think the real issue here is not on Apple's OS side (the OS supports vector graphics; that's why most of the graphics are actually scaling, but some smaller elements are not). The real issue is on the app side, where the particular app either just hasn't gotten the UI-update love (this isn't nearly as bad as the Win 3.1 Calculator they were still bundling with Vista, I believe, or the many Win 95/NT control panels which are still in Win 7/2008R2), or the particular graphics designer doesn't want to yield scaling control to the vectors. In this case, it appears the former, as there's not much that can go wrong in scaling a triangle onscreen.

 

[wankey]

Why? I bet they are all drawn in Illustrator and not Photoshop. It's actually easier to create them as vectors. How you implement them is different and harder one would imagine but surely Apple can manage it.



No I'm a graphic designer that uses both Illustrator and Photoshop. Admittedly I dont know how to implement the code for the UI but isn't the fact that a set size image is being scaled that makes it look "like ****?"

If it was a vector it would scale and not look like '****'.

It's all about performance and quality. Screens have pixels and you can't expect to put a vector display on a pixel screen and get the same kind of pixel perfection.

You guys don't really know what you're talking about when it comes to vector graphics.

Look at it this way, look at the fastest performing Flash GUI vs Quartz GL

 

[gmcalpin]

Well, that would need to be 4 vector graphics (isn't there a 32x32 usually as well? and I think you also have 256x256 and 512x512 to output as well).

Plus 1024x1024 for Hi-DPI. I wasn't trying to be comprehensive, hence the ellipses.

I think you just proved the opposite. You took one of the simplest graphics, and found that the bitmap only becomes larger than the SVG when that graphic is 512x512?

Not at all.

With bitmaps, you have to add ALL of those up (not in terms of processing, but in terms of file space), and once you start talking about having 8 (or more) versions of an icon to do them as bitmaps, versus 1, 2 or MAYBE 3 (for small, large, and supergigantic) for vector…

When you add up every file, folder and application that uses a unique icon, that adds up fast.

And when you need a UI to work well at multiple sizes, for every single graphic, that's even more unnecessary bloat. And when you're talking about UI elements, you don't need more than one version of an SVG.

I don't know about anybody else, but I would love to make the palettes in the Creative Suite about 25–30% larger. As my monitors get higher and higher res, the interface just keeps getting smaller, and I'm not getting any younger.

 

[Gruber]

Guys, this thread is depressing. It does not matter at all if we use vectors or bitmaps. We can simply provide a set of bitmaps at different resolutions an do the interpolation steps by downscaling them. Windows 8 is probably going to render its UI using HTML5 and will not care if you use bitmaps or vectors.

Also note that Apple users will have to live with a wide variety of DPIs for a long time to come. Resolution independence has been acceptable since Windows XP, and is for from experimental. It was never even experimental in MacOS (heck, it crashed XCode when you tried to turn it on). Apple's UI has originally been designed for a resolution of 72dpi (you still see this when you look at a document at 100%), and is now meant to work at about 95dpi.

However, Apple has increased the iMac resolution beyond 100dpi, and the some MBPs and MBAs are at >130dpi. Effing Heck. People older than 40 often run their Macs at reduced resolutions, even though everything becomes blurry.

Lion is a huge disappointment in that respect. Being able to switch between "too tiny to read" (70% the size the UI is designed for) and "too large to fit" (140% the intended size) is a piss-poor compromise.

 

[MacFly123]

Wow, i am really becoming interested in the 2012 redesigned MacBook Pros.

Ya me too! But I don't know if we will see a retina display that soon in a Mac. Apple is clearly working their way up starting with iPhone, next will be iPad retina display, and then they will be able to scale up to Mac size probably starting with the 11" MacBook Air, then 13", then the 15", 17" and so on as cost comes down and they scale up!

I'm glad Apple pushes the limits with cutting edge tech and finds ways to deliver it to the masses and force the industry to progress!

I can’t wait to say, “Oh, I don’t want to watch that 1080p video on my Mac, it’ll look like crap!”

BRING ON THE 4K VIDEO!!!

 

[SoftDel]

I reckon that the hardware is more than enough to provide vector based images.
I also think that the hard drive space is a moot point, anyway vectors will more likely be smaller based on the size of the elements we're talking about.

However I'm a software developer not a graphic designer, when I need to do my icons in my application, it's much easier to create bitmaps then vectors, the company I work does not have Photoshop/illustrator, do we need to now spend a considerable amount of money and time learning how to do.

Maybe in the future, when vectors are quick and easy to create.

 

[gmcalpin]

However I'm a software developer not a graphic designer, when I need to do my icons in my application, it's much easier to create bitmaps then vectors, the company I work does not have Photoshop/illustrator, do we need to now spend a considerable amount of money and time learning how to do.

Maybe in the future, when vectors are quick and easy to create.

Simple vector graphics such as for UI elements aren't hard to create. They can be slower, depending on what you want to do. It's less intuitive than a bitmap editor, sure, but if you can learn a programming language, you're smarter than me, and I do vector illustration for a living.

Also, there are plenty of free or cheap, low-end vector graphics editors. I think Inkscape is garbage, but other people swear by it. (I'm an Illustrator user, for lack of any better alternatives — but I need all its fancier features, and most people don't.)

 

[kalsta]

Apple Logo 16x16:
SVG: 16 vector points. 3 color swatches. 1 gradient. 95 KB (uncompressed SVG format).
PNG: 256 pixels. 32 bits per pixel (8 bits per RGB + alpha channel). 78 KB (compressed format, 82 KB uncompressed) …

Which version of the Apple logo is this? And how on earth are you coming up with those numbers for the bitmap? 256 pixels x 32 bits = 8192 bits = 1024 bytes = 1 KB. Not 82 KB. Am I missing something?

Your other uncompressed sizes would be as follows:

32 x 32 pixels: 4 KB
128 x 128 pixels: 64 KB
512 x 512 pixels: 1 MB
1024 x 1024 pixels: 4 MB

But since the context of this discussion is the representation of UI elements at their actual size, I can't see any relevance to the 128 x 128 and higher sizes.

Again, I challenge all the people here who keep telling us that vectors are inherently smaller than bitmaps — reproduce one of the traffic light window controls as a vector and keep it under 1 KB if you can!

There may be other good reasons to use vector graphics. Fine. But file size, when we're talking about small UI elements, ain't one of them. But go on, down vote my comment anyway! Sheesh.

 

[kalsta]

Simple vector graphics such as for UI elements aren't hard to create. They can be slower, depending on what you want to do. It's less intuitive than a bitmap editor, sure, but if you can learn a programming language, you're smarter than me, and I do vector illustration for a living.

Also, there are plenty of free or cheap, low-end vector graphics editors. I think Inkscape is garbage, but other people swear by it. (I'm an Illustrator user, for lack of any better alternatives — but I need all its fancier features, and most people don't.)

I'm an Illustrator user too — since version 3 if memory serves me correctly. For many things, vector graphics are clearly the best option. But I'd hate to have to create an entire UI using nothing but vectors. As I said before on this thread, bitmaps can always be generated from vectors but the reverse is not true. So if you had to choose only one for final output, bitmaps would give you by far the greater creative freedom.

 

[err404]

I'm an Illustrator user too — since version 3 if memory serves me correctly. For many things, vector graphics are clearly the best option. But I'd hate to have to create an entire UI using nothing but vectors. As I said before on this thread, bitmaps can always be generated from vectors but the reverse is not true. So if you had to choose only one for final output, bitmaps would give you by far the greater creative freedom.

Your conclusion seams reversed. Did you mean vectors?

Also, If you are starting with reasonably large/high contrast bitmaps, there are some pretty good tools for converting them to vectors (Illustrator and Inkscape to name a couple). Keep in mind that this will produce a rough draft that will require some touch ups and coloring. YMMV
Still, it is best for the OS to be format agnostic. Bitmaps can be scaled down with very little quality loss while vectors will help maintain sharp lines.

 

[kalsta]

Your conclusion seams reversed. Did you mean vectors?

No. When you use bitmaps for 'final output' it doesn't really matter how you create them — you can do it using any combination of vector and raster graphics, using the tools of your choice. This gives you great creative freedom. The same cannot be said when you have to output pure vector artwork.

 

[gmcalpin]

Again, I challenge all the people here who keep telling us that vectors are inherently smaller than bitmaps — reproduce one of the traffic light window controls as a vector and keep it under 1 KB if you can!

In a couple of minutes, I made this (the attachment).

It's an SVGZ file (so it's compressed; the uncompressed version is about 1,013 bytes), and I'm skimping on the number of steps in the blend, so it only looks good at 100% size (at least on my Cinema Display here at work) — but the actual data in the file is 552 bytes.

The real advantage of vectors is the scalability, though. If you want to do a "hi-DPI" version of the traffic light, you would just do a more detailed SVG file and scale it. For a bitmap, you'd need multiple files at various sizes. (Or one larger one and scaling it down, which would probably make any processor advantage to using bitmaps a wash versus using vectors.)

This has all be covered earlier in the thread, though. It's all getting very circular.

And err404: his idea of creative freedom (if I'm understanding him right) is the ability to design whatever you want — but that comes at the price of the freedom of the user to determine how big he wants the UI to appear.

This is what our conversation here has ultimately revolved around: Is it more important to cater to software developers' wishes, or the myriad needs of a billion-some-odd users?

All other things being equal, is it better to have, say, a calculator program that is one fixed size, or one that can be scaled as big as the user wants it?

 

[Bytor65]

Why are these exclusive? Roll the pixel doubled solution now but also lay the frame work for resolution independence in 5 years...
I would love to be able to scale my desktop windows smaller to fit more information and then scale them larger for some casual browsing. Today's solutions don't easily allow this.

How much effort/interest do you think there is in Vectorizing everything on the iPhone now that it has a "Retina" Display, same with iPad once it transitions to it's doubled resolution, and likely the same after the desktop transitions.

I use Windows7 and it has arbitrary scaling. But there is one huge caveat, it works correctly in almost no third party applications. In fact it is a total mess in third party applications.

If Apple can achieve a pixel doubling jump that actually benefits third party software this will be a major win.

The majority of people (including developers) aren't really going to care about making everything vector based. Bitmaps are just simpler to use and more than good enough.

Once we have HiDPI capability there will simply be bigger fish to fry than chasing a Vector based OS as some philosophical battle.

 

[kalsta]

In a couple of minutes, I made this (the attachment).

It's an SVGZ file (so it's compressed; the uncompressed version is about 1,013 bytes), and I'm skimping on the number of steps in the blend, so it only looks good at 100% size (at least on my Cinema Display here at work) — but the actual data in the file is 552 bytes.

Hey, that's pretty good! It's obviously missing some of the subtle details of the real ones, so it's not quite there… But still, I'm impressed that someone finally took the challenge and, to be honest, did a better job than I was expecting.

The real advantage of vectors is the scalability, though. If you want to do a "hi-DPI" version of the traffic light, you would just do a more detailed SVG file and scale it.

Agreed.

For a bitmap, you'd need multiple files at various sizes.

Only if you want pixel-perfect control. Otherwise you just create a big bitmap and scale it, like they do with application icons.

And err404: his idea of creative freedom (if I'm understanding him right) is the ability to design whatever you want — but that comes at the price of the freedom of the user to determine how big he wants the UI to appear.

You lost me a bit there. I think err404 was possibly confusing publishing freedom with what I was calling creative freedom. Once you've created a vector image, it's almost like a 'create once, publish anywhere' setup. You have the freedom to output to vectors or bitmap. But that's not creative freedom. If you want the freedom to create using either bitmap or vector, or any combination of the two, then you're limited to bitmap output.

This is what our conversation here has ultimately revolved around: Is it more important to cater to software developers' wishes, or the myriad needs of a billion-some-odd users?

All other things being equal, is it better to have, say, a calculator program that is one fixed size, or one that can be scaled as big as the user wants it?

Well, that's a good question. I'm tempted to answer that both are important. Perhaps that's Apple's take too, and why we're now looking at a sort of half-way compromise regarding resolution independence. Or perhaps it's because Apple doesn't trust developers (or even their own software) to be able to deliver a satisfactory standard if they're handed true resolution independence.

 

[kalsta]

Once we have HiDPI capability there will simply be bigger fish to fry than chasing a Vector based OS as some philosophical battle.

Well said sir!

Then the only ones who will be left out will be those who bought a 2010 or 2011 MacBook Pro with the build-to-order high-res display (which is half-way between standard and HiDPI) because they wanted anti-glare! Oh wait a minute — that's me.

 

[err404]

No. When you use bitmaps for 'final output' it doesn't really matter how you create them — you can do it using any combination of vector and raster graphics, using the tools of your choice. This gives you great creative freedom. The same cannot be said when you have to output pure vector artwork.

Got it. I was thrown by your example stating the limitations in converting formats followed by a conclusion of the more restrictive format being preferred.

At the end of the day, it depends upon what you are producing. UI elements are generally not to flashy (high contrast and simple forms), making vectors a good choice. But it is certainly more complex for heavily detailed, shaded or textured works.

 

[gmcalpin]

Hey, that's pretty good! It's obviously missing some of the subtle details of the real ones, so it's not quite there… But still, I'm impressed that someone finally took the challenge and, to be honest, did a better job than I was expecting.

Thanks! Yeah, it's definitely missing the littler details. If I had a high-res image of the light to compare it against (and more time), I'm pretty sure I could match it exactly — but it would definitely come out to more than 1kb. I was aiming to beat your file size constraint more than anything else, really.

 

[err404]

How much effort/interest do you think there is in Vectorizing everything on the iPhone now that it has a "Retina" Display, same with iPad once it transitions to it's doubled resolution, and likely the same after the desktop transitions.

It's hard to compare the constraints of a handheld device to a desktop. For one, the phone UI elements are constrained by the usable size of a touch interface more so than visual limitations. Also a phone is a hand-held device that can effortlessly be brought closer to your face to 'enlarge' small elements. A desktop on the other hand sits at a fixed distance from you. A 1 to 1 pixel UI on a desktop has the disadvantage of being directly tied to the monitor DPI and sitting position of the user. Today if you want to fit more/less information on the same size screen, you need to purchase a screen with different DPI. Your personal preference is defined by your initial hardware purchase as opposed to a user defined setting.

Will people just accept it as good enough? Probably. I'm just disappointed that Apple may be abandoning the work that they have been doing since OS X 10.4 on true system wide resolution independence.
http://en.wikipedia.org/wiki/Resolution_independence
FYI - Windows never had true resolution independence, rather MS implemented adaptive font scaling.

 

[kalsta]

Thanks! Yeah, it's definitely missing the littler details. If I had a high-res image of the light to compare it against (and more time), I'm pretty sure I could match it exactly — but it would definitely come out to more than 1kb. I was aiming to beat your file size constraint more than anything else, really.

Well, I think I said I would eat my MBP if anyone even got close to the same file size, so… I might have to invest in one of those fancy blenders now. Thanks a lot!!

 

[jglavin]

Given the history between Apple/LG that 27" version is almost certainly an Apple request. There will be a premium, but it will be more like a few hundred dollars more, not thousands. There is nothing really that challenging about building 166 dpi display in 2011.

A 27" 3840x2160 screen will give the iMac a huge boost in mindshare and is a perfect fit with everything before. 2012 or 2013 at the latest IMO.

Sure it is guesswork, but it is based on many clues both form Apple and LG and the strong relationship between the companies.

This, and also keep in mind another thing: You can't use current pricing for hi-dpi monitors as an indicator of what they will cost in a high-volume product like a Mac.

Does anyone else remember that mysterious several-billion-dollar investment they mentioned a quarter or two ago during the earnings call? Yeah, that was probaby them commissioning this exact thing, a 166dpi, 27" panel for future iMacs and displays.