7 ms·

iOS still doesn't have proper resolution independence, hence hacks like this. There's no reason to be doing post scaling on a rendered image unless you have poo

iOS still doesn't have proper resolution independence, hence hacks like this. There's no reason to be doing post scaling on a rendered image unless you have poor software which can't render at the proper resolution in the first place. If anyone else did this they'd be pilloried for it being the total battery wasting font-destroying hack that it is, but Apple gets away with it. This is true on the Macbook Retinas also - when I set mine to looks like 1680 or 1920, fonts get blurry due to this scaling, when if the software was better it'd be rendered at the native resolution and they would look as good as they do at the 2x resolution. (where the numbers work out that you can scale without a loss of fidelity)

TazeTSchnitzel 12y ago
Are you sure? I think iOS is resolution-independent, they just chose to do this since a 3x scale factor is more convenient. EDIT: It also sounds like it was originally going to be the correct resolution, they just couldn't get the yields. If that's the case, perhaps they made it downscale at the last minute and used a 1080p panel?
- leoc 12y ago
  > It also sounds like it was originally going to be the correct resolution, they just couldn't get the yields. I strongly assume that the lower resolution was indeed Plan B, and that it's the result of another twist in the saga of Apple's relationships with the mobile component suppliers. On a not-really-unrelated note, the Samsung Galaxy Note 4's screen is apparently pretty stellar in all respects, not just resolution: http://www.displaymate.com/Galaxy_Note4_ShootOut_1.htm http://www.displaymate.com/Galaxy_Note4_ShootOut_1.htm .
- jordanthoms 12y ago
  Why should 3x be any more convenient than 2.5x or 2.2x in a properly designed system? It's not any more difficult in Android (although images are prescaled in size buckets for efficiency and IQ reasons).
  - ridiculous_fish 12y ago
    A 1 dip line is sharp at 1x or 3x, but requires antialiasing at 2.5x or 2.2x.
terhechte 12y ago
In Apple's defense, they've been working on full resolution independence since 2005 or so, with a setting for developers available from Leopard (2007) on, where one could set the resolution in between 1x to 3x. However, due to the complexity of the issue, Carbon apps, and probably a lot of other things, that never worked really well. I've been playing around with it with each new OSX release, until they removed it (I think Lion or Mountain Lion). Basically, I think they never got it working good enough and just fixed it to 1x and 2x. Here's a screenshot from the utility they had for this. http://i.stack.imgur.com/0NToe.png http://i.stack.imgur.com/0NToe.png
ridiculous_fish 12y ago
I worked on resolution independence on OS X over a period of years. I think the above comment is not made with full appreciation of the difficulty of the problem. Supporting arbitrary resolutions well is very difficult. The underlying frameworks (e.g. CoreGraphics) are absolutely capable of rendering at arbitrary resolutions, and have been for a long time. It's not particularly hard: you interpose an affine transform which converts from local to device coordinates, apply it to all your geometry, and it falls out. But "rendering at arbitrary resolutions" is not the same as "looks good at arbitrary resolutions." For example, a line 1 px wide at 1x will be 1.5 pixels wide at 1.5x. That means at least one edge must be aligned on a partial pixel, and there's the potential for weird antialiasing effects. There's also a behavior change: you cannot redraw half a pixel, so now "dirtying" a pixel requires redrawing more components at 1.5x than at 1x, which can cause performance problems and other bugs. And there's also a question of which pixels get the partial alignment: do you round in a direction? If so, which one? Or maybe you don't round and you have two pixels that are a quarter covered? Which leads to the problem of centering. I wish to center a bitmap image within a button's border. The image is 101 logical points high, and the border is 200 logical points high. With a 2x scale factor, I can center absolutely, and still be aligned to device pixels. With a 1x, 1.25, 1.33, etc. scale factor, centering will align me on a partial pixel, which looks like crap. So I have to round. Which way? If the goal is "make it look good," then the answer is "whichever way looks good," which depends on the visual style of the bezel, i.e. whether the top or bottom has more visual weight. So now we need hinting. And that's where things start to get really nasty. In order to make things look good at arbitrary resolutions, we want to round to device pixels. But the rounding direction is not a local question! Consider what happens if we have two visual elements abutting in logical coordinates, and they round in opposite directions: now there's a device pixel between them. That's very visible: you get a pixel crack! So you have to coordinate rounding. WPF is a good example of a framework that attempted resolution independence and encountered this problem. Initially it has the "SnapsToDevicePixels" property, which triggers rounding behavior at draw time. But draw time is too late, because of the "abutting elements rounding in opposite directions" problem. So they introduced the "UseLayoutRounding" property, which does...something. And the guidance is basically "turn it on and see if it helps, if not, disable it." Great. The web also has this problem in spades. Websites break in all sorts of fun ways when you zoom in or out. We tolerate this because, frankly, the bar is super-low for websites. As I see it, the two options are: 1. Make everything vectors. You'll have to choose between weird antialiasing artifacts and potential pixel cracks; either way things will look bad. And you'll encounter bitmaps eventually, and have to deal with the necessities of resampling and pixel aligning at that point. 2. Scale only to integral sizes, and resample. You'll avoid antialiasing and pixel alignment issues, but pay a performance penalty, and things may look slightly blurry. So which option is better? #1 has the potential for the highest-quality output, but at a significant price: developers must test their apps at more scale factors, and the failure mode is ugly drawing artifacts or outright bugs. #2 is more utilitarian: the output is not as nice, and you incur a perf penalty, but that's borne by the system instead of the apps, and the overall system is more consistent. #2 is also more forward looking: if you expect that pixel densities will continue to increase, then resampling artifacts will eventually be indiscernible, but a pixel crack will always be visible. Apple took the practical and forward-looking approach to this problem. I can't fault them: to my knowledge, nobody has successfully implemented true resolution independence in a framework with wide adoption. If they have, I'd love to know how!
joakleaf 12y ago
Regarding blurry fonts on you Macbook Retina: It only makes sense to set the resolution to match the number of hardware pixels. You cannot change the resolution of the hardware display, so any resolution other than the native resolution will look blurry as the system has to resample to match the hardware. This has nothing to do with OSX -- OSX can render fonts in any resolution. ... You can easily connect your Macbook Retina to an external monitor of any resolution. OSX is not limited to your Macbook Retina resolution. On the iPhone6+ Apple could easily draw everything in 2.6x resolution to match the display, but I guess they feel using 3x+downsampling simplifies the UI-design process. From a technical point of view it is an unnecessary hack.
- jordanthoms 12y ago
  The problem here is that you are conflating resolution with how big things are. They aren't the same. I want the resolution on my Macbook to always be 2880x1800. But I want to be able to make things bigger or smaller, while still rendering at that resolution so things don't have to be resampled. (and in the case of the iPhone 6+, the default/only setting requires this resampling). The problem is that when I set it to 'looks like 1680', rather than just rendering things natively at 2880x1800 but a little bit smaller, we have to get into all these scaling hacks (rendering at 3360 x 2100 and then scaling down to 2880x1800), which means you lose the accurate font rendering and clarity you got, everything has a slight blur to it because it's been scaled down.
  - bluedino 12y ago
    For this reason I much prefer how fonts look in Safari by scaling the browser down, and running at 'Best for Retina' instead of running at 'looks like 1440x900' and then leaving the fonts at the normal scale.
saturdaysaint 12y ago
"If anyone else did this they'd be pilloried for it being the total battery wasting font-destroying hack that it is, but Apple gets away with it." Except we're talking about a phone that sits at or near the top of every battery life shoot out chart. And the pickiest screen-specific shootouts fail to mention any difference in font detail between iPhone models. Some hacks work.
archagon 12y ago
It looks like the plan for resolution-independence on Apple platforms is "get the DPI so high that you can set the screen size to whatever you want". And I'm OK with that. Not everything can be represented with vector graphics.

TazeTSchnitzel 12y ago

Are you sure? I think iOS is resolution-independent, they just chose to do this since a 3x scale factor is more convenient. EDIT: It also sounds like it was originally going to be the correct resolution, they just couldn't get the yields. If that's the case, perhaps they made it downscale at the last minute and used a 1080p panel?

leoc 12y ago
> It also sounds like it was originally going to be the correct resolution, they just couldn't get the yields. I strongly assume that the lower resolution was indeed Plan B, and that it's the result of another twist in the saga of Apple's relationships with the mobile component suppliers. On a not-really-unrelated note, the Samsung Galaxy Note 4's screen is apparently pretty stellar in all respects, not just resolution: http://www.displaymate.com/Galaxy_Note4_ShootOut_1.htm http://www.displaymate.com/Galaxy_Note4_ShootOut_1.htm .
jordanthoms 12y ago
Why should 3x be any more convenient than 2.5x or 2.2x in a properly designed system? It's not any more difficult in Android (although images are prescaled in size buckets for efficiency and IQ reasons).
- ridiculous_fish 12y ago
  A 1 dip line is sharp at 1x or 3x, but requires antialiasing at 2.5x or 2.2x.

terhechte 12y ago

In Apple's defense, they've been working on full resolution independence since 2005 or so, with a setting for developers available from Leopard (2007) on, where one could set the resolution in between 1x to 3x. However, due to the complexity of the issue, Carbon apps, and probably a lot of other things, that never worked really well. I've been playing around with it with each new OSX release, until they removed it (I think Lion or Mountain Lion). Basically, I think they never got it working good enough and just fixed it to 1x and 2x. Here's a screenshot from the utility they had for this. http://i.stack.imgur.com/0NToe.png http://i.stack.imgur.com/0NToe.png

ridiculous_fish 12y ago

I worked on resolution independence on OS X over a period of years. I think the above comment is not made with full appreciation of the difficulty of the problem. Supporting arbitrary resolutions well is very difficult. The underlying frameworks (e.g. CoreGraphics) are absolutely capable of rendering at arbitrary resolutions, and have been for a long time. It's not particularly hard: you interpose an affine transform which converts from local to device coordinates, apply it to all your geometry, and it falls out. But "rendering at arbitrary resolutions" is not the same as "looks good at arbitrary resolutions." For example, a line 1 px wide at 1x will be 1.5 pixels wide at 1.5x. That means at least one edge must be aligned on a partial pixel, and there's the potential for weird antialiasing effects. There's also a behavior change: you cannot redraw half a pixel, so now "dirtying" a pixel requires redrawing more components at 1.5x than at 1x, which can cause performance problems and other bugs. And there's also a question of which pixels get the partial alignment: do you round in a direction? If so, which one? Or maybe you don't round and you have two pixels that are a quarter covered? Which leads to the problem of centering. I wish to center a bitmap image within a button's border. The image is 101 logical points high, and the border is 200 logical points high. With a 2x scale factor, I can center absolutely, and still be aligned to device pixels. With a 1x, 1.25, 1.33, etc. scale factor, centering will align me on a partial pixel, which looks like crap. So I have to round. Which way? If the goal is "make it look good," then the answer is "whichever way looks good," which depends on the visual style of the bezel, i.e. whether the top or bottom has more visual weight. So now we need hinting. And that's where things start to get really nasty. In order to make things look good at arbitrary resolutions, we want to round to device pixels. But the rounding direction is not a local question! Consider what happens if we have two visual elements abutting in logical coordinates, and they round in opposite directions: now there's a device pixel between them. That's very visible: you get a pixel crack! So you have to coordinate rounding. WPF is a good example of a framework that attempted resolution independence and encountered this problem. Initially it has the "SnapsToDevicePixels" property, which triggers rounding behavior at draw time. But draw time is too late, because of the "abutting elements rounding in opposite directions" problem. So they introduced the "UseLayoutRounding" property, which does...something. And the guidance is basically "turn it on and see if it helps, if not, disable it." Great. The web also has this problem in spades. Websites break in all sorts of fun ways when you zoom in or out. We tolerate this because, frankly, the bar is super-low for websites. As I see it, the two options are: 1. Make everything vectors. You'll have to choose between weird antialiasing artifacts and potential pixel cracks; either way things will look bad. And you'll encounter bitmaps eventually, and have to deal with the necessities of resampling and pixel aligning at that point. 2. Scale only to integral sizes, and resample. You'll avoid antialiasing and pixel alignment issues, but pay a performance penalty, and things may look slightly blurry. So which option is better? #1 has the potential for the highest-quality output, but at a significant price: developers must test their apps at more scale factors, and the failure mode is ugly drawing artifacts or outright bugs. #2 is more utilitarian: the output is not as nice, and you incur a perf penalty, but that's borne by the system instead of the apps, and the overall system is more consistent. #2 is also more forward looking: if you expect that pixel densities will continue to increase, then resampling artifacts will eventually be indiscernible, but a pixel crack will always be visible. Apple took the practical and forward-looking approach to this problem. I can't fault them: to my knowledge, nobody has successfully implemented true resolution independence in a framework with wide adoption. If they have, I'd love to know how!

joakleaf 12y ago

Regarding blurry fonts on you Macbook Retina: It only makes sense to set the resolution to match the number of hardware pixels. You cannot change the resolution of the hardware display, so any resolution other than the native resolution will look blurry as the system has to resample to match the hardware. This has nothing to do with OSX -- OSX can render fonts in any resolution. ... You can easily connect your Macbook Retina to an external monitor of any resolution. OSX is not limited to your Macbook Retina resolution. On the iPhone6+ Apple could easily draw everything in 2.6x resolution to match the display, but I guess they feel using 3x+downsampling simplifies the UI-design process. From a technical point of view it is an unnecessary hack.

jordanthoms 12y ago
The problem here is that you are conflating resolution with how big things are. They aren't the same. I want the resolution on my Macbook to always be 2880x1800. But I want to be able to make things bigger or smaller, while still rendering at that resolution so things don't have to be resampled. (and in the case of the iPhone 6+, the default/only setting requires this resampling). The problem is that when I set it to 'looks like 1680', rather than just rendering things natively at 2880x1800 but a little bit smaller, we have to get into all these scaling hacks (rendering at 3360 x 2100 and then scaling down to 2880x1800), which means you lose the accurate font rendering and clarity you got, everything has a slight blur to it because it's been scaled down.
- bluedino 12y ago
  For this reason I much prefer how fonts look in Safari by scaling the browser down, and running at 'Best for Retina' instead of running at 'looks like 1440x900' and then leaving the fonts at the normal scale.

saturdaysaint 12y ago

"If anyone else did this they'd be pilloried for it being the total battery wasting font-destroying hack that it is, but Apple gets away with it." Except we're talking about a phone that sits at or near the top of every battery life shoot out chart. And the pickiest screen-specific shootouts fail to mention any difference in font detail between iPhone models. Some hacks work.

archagon 12y ago

It looks like the plan for resolution-independence on Apple platforms is "get the DPI so high that you can set the screen size to whatever you want". And I'm OK with that. Not everything can be represented with vector graphics.