Hacker News Reader

> Even if an application has no modifications for retina displays, it will look mostly right (minus some blurring issues for pixel art). There will be no scaling issues, no texts will be cropped and everything will be scaled to the same factor.

That is how it (should) work in Windows too. All applications that do not explicitly claim to be DPI aware get just bitmap scaled, just like on OSX.

The real problem is that tons of applications claim to be DPI aware, but in reality are not. The reason Apple does not have these kind of issues is that their Retina thing is more recent and thus there are no legacy apps that claim to be DPI aware.

> All applications that do not explicitly claim to be DPI aware get just bitmap scaled, just like on OSX.

I don't believe that is true. If you render text using the right high-level OS X APIs, your OS-provided vectors are rendered natively without being bitmap scaled.

WPF can do this just fine also, but few apps are written in WPF :p (well, WinRT inherits this nice property). GDI, I'm not sure....

> All applications that do not explicitly claim to be DPI aware get just bitmap scaled, just like on OSX.

That isn't what happens for Cocoa apps on OSX, though. Non-retina-aware apps aren't bitmap scaled; the Cocoa UI stuff is still scaled up properly (XBench, which had its last release in 2006 targeting MacOS 10.3, looks perfectly sharp on an rMBP, for instance). It's just non-standard stuff that may be a problem.

> The reason Apple does not have these kind of issues is that their Retina thing is more recent and thus there are no legacy apps that claim to be DPI aware

Not actually true. Many games are fairly messed up in either windowed, full-screen, or both noises. Usually it's because of a bad middleware toolkit that either enables the Retina backbuffer our not but the OpenGL scaling doesn't match the window scale. Especially prominent in games that use the older, Carbon method of exclusive full screen mode.

Aside: full screen games manage to be even worse on OS X than on Windows. That takes effort. (Games as full screen spaces is a really nice, usable concept, but the performance hit is so nasty nobody wants to support it instead of the invasive and messy Core Video tour.)

(aside: This post was doubly a victim of autocorrect. s/noises/modes/ and s/tour/route/. My bad.)

Mac does this even better. It does allow arbitrary scaling - for some definitions of arbitrary.

For example, my MBPR 13" is set to the setting between "Best (Retina)" (which is the exact 2x, 1280x800 I think) and "More space") (which is 1.52x, 1680x1050), so I get 1.77x the space (1440x900). You control the DPI there and everything remains nice and sharp.

Apps aren't even aware of this scaling, so everything works perfectly well.

Yeah. But the virtual resolutions are fixed depending on the screen. There's no way to arbitrarily set a virtual resolution and the OS only offers this for screens it knows (see the MacPro Review from anandtech where they tried to enable HDPI with that 4K display: the os only offered the 2x mode).

That's why I wouldn't call that arbitrary scaling. If they could offer it using their method, I'm sure they would.

It's not exposed in the settings, but it can scale to any apparent resolution. There are various 3rd party programs that can set any apparent resolution for you.

And of course, you can see this without any 3rd party software if you connect it to a monitor or projector with a weird resolution and enable mirror mode.

I get what you're saying, but this is probably not a great way to think about it because it isn't arbitrary scaling, it's arbitrary backbuffer resizing. The way this works internally is to render to a HiDPI buffer at 1680x1050 Cocoa points (mapping pixels:points at 2:1). It's still @2x, the buffer just gets downsampled afterwards and the pixel density is high enough that it's difficult to tell in practice.

> Mac OS did this too - I think in the 10.4 timeframe there was an option to actually switch into a higher DPI mode and many of the OS-internal UI assets were vector images

There was, though the assets were big scalable bitmaps, not vectors (even on modern HiDPI Macs, the UI assets are still way too big). John Siracusa covers a lot of this (and complains about it not being used) in his MacOS reviews.

> Yes. The Apple solution is a hack. Yes, it doesn't allow scaling to arbitrary factors.

It actually does, through a _really_ horrible hack. Say you want 1680x1050 _point_ resolution on a 2880x1800 MBP. You can select that; what the OS then does is draws at 3360x2100, then scales it down to 2880x1800. Sounds horrible, but generally works very nicely.

It's worth noting, by the way, that Metro scaling works much like MacOS scaling; it's only the desktop that uses the older style.

This hack does require a high DPI screen though. If you have a normal monitor on OS X, and just want to make stuff a bit bigger, it's going to look like crap.

I don't see what's so horrible about how Apple handles resolutions for retina Macs. It lets me have a HiDPI screen that either 1) shows the app in HiDPI the way it was meant to be or 2) (worst case) doubles all the pixels, making it about the same quality as 1x screens before. It also gives me flexibility in getting more space than native retina resolution without having too much blur. Furthermore, something that is great for accessibility reasons, it finally allows lower resolutions without having a blurry picture. A killer feature for my father - the upgrade in screen quality from his old Lenovo running at 2/3 native resolution and his 15' Retina is insane.

Oh, it works pretty well; I have an rMBP myself and like the feature. I just find it conceptually awful :)

Apple did have a solution in place for several releases that supported arbitrary scaling. It could be enabled via a developer tool. I'm guessing the 2x solution came about once they realised getting all of their developers to rewrite for arbitrary scaling was impractical.

I think it was much more urgent than that. They wanted to ship actual retina displays on actual Macs on a defined product cycle. They had a hard date by which this HAD to work. Getting developers to rewrite eventually is one thing, getting them to rewrite in time for the release of a specific product in 12 months time is another.

If Sony is planning to release a HiDPI Windows laptop, whether it works well is a problem for who? Sony? Microsoft? Every Windows app developer ever?

If Apple releases a laptop with a Retina display, it's Apple's problem. No ifs or buts. Everyone knows exactly where the buck stops.

I think Apple also realised that the 2x solution is all they will need. There is very little point going higher density than the current 15" rMBP display. So there is little point in supporting completely arbitrary resolutions — Apple are betting on this density as the standard for the future.

I think they also realise that our current "2x" solution is our future software's "1x" scale factor. When Apple's line of hardware is retina-only, we'll probably see them drop support for the distinction between 1x and 2x. Everything will simply become designed for the current density.

I think it'll stick around for a long time, due to external displays: projectors, TVs, etc... which either don't benefit a great deal or won't be upgraded to hiDPI for a long time.

I posted a separate comment to the effect that the Apple solution also allows using both hi- and regular-DPI displays simultaneously with no issues.

Given the push to 4K on TVs and other video viewing devices, it seems like they'll catch up fast enough. 4K at the typical viewing distances is pretty close to retina in terms of the number of degrees of your vision each pixel covers.

To me this was the key insight. There was this idea of a slowly, ever-increasing display density that we'd have to handle by making everything be vector based, since bitmaps don't scale -- which has a grain of truth, and a certain aesthetic beauty.

But in practice, the human eye has limits so density is not going to increase forever, and we only have a known, finite set of displays to support. So just provide bitmaps for the display densities that matter. Boom. Problem solved.

(Probably forever, depending on how much you believe the "retina" marketing claim -- the difference between the type on e.g. a retina display mac and a magazine seems small enough to me that I could easily imagine a push to "super-retina" not happening in my lifetime.)

I was actually shocked at how badly Apple handled Retina, and even more shocked and disappointed that Windows did it worse.

Apple basically made everyone rewrite their apps instead of doing something sane - though admittedly they never had real support for multi-dpi, so perhaps that's an at least understandable solution.

Microsoft have always had support for changing the DPI in the operating system, but in Windows 8.1 instead of reusing that support and improving the code so that you don't need to log out and back in to change DPI they instead started doing Retina-style scaling - but far worse.

High-DPI apps (edit: non-Metro, I should clarify) in Windows 8.1 actually don't look good on a low-DPI screen. (You need an e.g. Retina main screen and a standard external monitor to experience this.) Sure, they look a lot better than the pixelly stuff on the main screen, but instead of rendering at standard DPI Windows instead renders at high DPI and linearly scales down the resulting image in the window manager, resulting in text that looks strangely off because it has been rendered at high DPI with appropriate hinting and then scaled down.

This is not to mention what happens when you have a program half on one monitor, half on the other... it's either tiny on one screen or humungous on the other. Retina at least does this beautifully.

> Apple basically made everyone rewrite their apps instead of doing something sane - though admittedly they never had real support for multi-dpi, so perhaps that's an at least understandable solution.

They did not make everyone rewrite their apps. The only apps that actually needed to change were the ones that were rendering text without using the Text rendering APIs of the OS (a small minority of apps).

Everything else just worked totally fine.

Yes, some icons might have been blurry, but functionality-wise everything was fine.

This is in contrast to Windows where switching to HiDPI mode usually means cut-off texts, invisible buttons (pushed out of the dialogs they are in) and, as noted by the OP, sometimes a mish-mash of correct and incorrect rendering within the same window.

You tell us you were shocked by how it was handled by Apple, so what would you have done differently? How would you have solved the issue in a way that requires even less work by app developers?

Honest question. I really can't imagine a better solution than what Apple has done, but then again, the bulk of my knowledge is in databases, web servers, web applications and devops, so I'm sure I miss something that you can see. Hence I'm asking.

One cool thing about the way that Apple do drawing is that (at least on iOS, I think on OS X too (CG* APIs) - I'm making the assumption this is a PostScript/Display PostScript holdover) the drawing APIs use floats for positioning instead of integers. So a retina pixel is just a whole number pixel+0.5. This was a pain before retina screens appeared, since anything not positioned on a whole number would render blurry. But then retina displays appeared and the reason for it clicked.

I doubt it's because of HiDPI. I expect it comes more from the GL heritage inherent in the system, where the pixel/texel ratio can be anything you want.

No, he got it right the first time: it's due to the PostScript heritage. Cocoa predates OpenGL. Back in the '80s, HiDPI was called print resolution, and applications used the same commands to draw to screen or paper years before TrueType was available. (Though NeXT systems did typically use raster fonts for most on-screen use because PS wasn't very good at antialiasing or hinting.)

In fairness, high-DPI screens on Windows are a new thing. If (and I realize it's a big if) apps get fixed over the next couple of years to handle different DPI settings, then the end result will be a lot more usable for e.g. vision-impaired users who want to use a higher DPI setting than the default.

Not a new thing at all. I had an Acer laptop back in 2006 that run XP and that actually came configured with High DPI. Took me a while to find how to switch it back to the default, but the point is that even XP was DPI-aware.

Sure. I ran windows (presumably 2000?) with high DPI back in 2002 (on a good ol' 2048x1536 CRT - it's pathetic how long it's taken vertical resolution to catch up to where we were. But I digress). But apps weren't written to support it, and many of them had the kind of problems you see in this post.

Not to mention, on a Mac you can have a combination of hiDPI (internal display on rMBP) and regularDPI (external display) and it works seamlessly. I'm going to take a guess and say the same isn't true for Windows?

Yeah, what happens if you put a window halfway between two displays in Windows? On OS X, the window goes non-retina on both.

They "fixed" this in Mavericks by only allowing a window to be on one screen. The window only renders on the monitor it is the majority on.

That's kind of sad. Dragging windows seamlessly across monitors has been one of those cool Mac tricks since approximately 1987.

It is easy to revert to the previous behaviour: uncheck "Displays have separate Spaces" in Mission Control under System Preferences.

Mavericks treats multiple displays as unique desktops now, to enable for example separate Full Screen modes for each display.

Good to know. I have no interest in upgrading to Mavericks and even less interest in full screen mode, but at least now if I ever end up there by accident, I'll be able to get back out!

Yes, the complaints about full screen mode not working on multiple monitors always seemed idiotic to me. Full screen mode is designed for small laptop screens, to free up some extra screen real-estate. Not for multiple displays.

He said that it works seamlessly. You're putting a window on a seam, so it doesn't work, duh.

Windows does support per-display DPI settings. Windows do get scaled when dragged from one display to another.

And what of Android?