3 ms·

What about Android? The layout managers there attempt to get good placing of items, dealing with these issues. Agreed it's a hard problem and that comment was

What about Android? The layout managers there attempt to get good placing of items, dealing with these issues. Agreed it's a hard problem and that comment was certainly reductionist, but at the same time it's depressing to have this be the issue that makes fonts blurry - the hardware is fine but the software side is letting it down.

acqq 12y ago
> at the same time it's depressing to have this be the issue that makes fonts blurry Wait, have you actually seen blurry fonts on the iPhone 6 Plus? Do you know of any photograph which demonstrates them?
- rsynnott 12y ago
  Somebody with abnormally good eyesight probably could if they knew what they were looking for.
  - acqq 12y ago
    I'm asking for a photo, even with a microscope. I'm really curious, because I still believe the difference can't be seen for the text sizes that are actually readable by humans that don't use magnifying glasses.
ridiculous_fish 12y ago
My understanding is that Android uses essentially the same strategy as iOS: don't attempt to support full resolution independence, but instead enumerate a set of supported DPIs. See the DisplayMetrics class: there's an enumeration of supported densities, and the 'density' property itself is noted as being a "gross" measure that is rounded to nice values, like 1.5. Of course extra space can absorbed into the screen size instead of its density. Android and iOS support this via their respective mechanisms, like autoresizing masks or autolayout on iOS, and I guess layout managers on Android. If you were to make a new device with unusual screen metrics, you have a few options for app compatibility. You could report an unusual density, and risk ugly antialiasing or pixel cracks. Alternatively, you could report an unusual size, and get bad layouts, where lots of apps will have UI elements overly small, and excessive unused space. Or you could compromise: report sane (but inaccurate) sizes and densities, and resample. This maximizes compatibility, with some quality and performance cost. (The idealized option is true resolution independence, where apps look great at any density and size. To my knowledge, nobody has achieved that.) I figure Apple realized that the iPhone 6+ would be very heavily reviewed, and so wanted to ensure that existing apps would work really well on it. That's what their scaling approach enables.
- kllrnohj 12y ago
  No, the DPI buckets are only for pre-baked assets (images, basically). Everything else is fully resolution independence. This was used for the original N7, for example, which didn't actually fit into either the MDPI or the HDPI buckets. It instead had a ratio of 1.33125, and yet everything but images are rendered unscaled.
  - ridiculous_fish 12y ago
    Interesting. So what would happen if you drew, say, a 100 dip box on an N7? Would two edges just be blurry?
    - jordanthoms 12y ago
      On Android, drawing happens at directly on the output framebuffer, using pixel values. So If you were directly drawing a box, you'd have to convert 100dip into a px value and round it in some direction. But you wouldn't actually do that apart from in rare circumstances - instead, you'd create a View, size it to 100dip, and give it to a layout telling it to position it in say the center of the screen. When it's displayed, the layout manager will decide how big to actually draw it, taking the density into account. Android doesn't have the issues with pixel cracks etc you are talking about, since the views are all stored in Layout Managers which operate at the native device resolution and calculate the final positioning. So they can see that this element would be 10.5px, display it at 10px, and move the next element up by 1px so everything works out.
      - ridiculous_fish 12y ago
        I worked on autolayout, which does exactly what you describe: attempt to derive a pixel-aligned layout from abstract positioning rules. It was very difficult, so I'm skeptical that Android has found a way to just make "everything work out." The mathematics requires some sort of tradeoff. For example, say we have 10 views, alternating black and white, each 10 dips wide, packed abutting into a container of width 100 dips. At 1.33x scale, each view wishes to have 13.3 device pixels. How do Layout Managers solve this? 1. Round each view down to 13 pixels, and repeatedly "move the next element up" by 1 px? Then you must account for .3 * 10 = 3 unclaimed pixels at the end of your container. That's going to be quite visible. 2. Round views based on their fractional pixel position, i.e. seven views down to 13 pixels, and three views up to 14? Now your stripes have different widths, which can be visible (especially if they have high-frequency content), and can also cause a "creeping" effect when they animate, if their edges are rounded independently. 3. Don't round at all, and position views on fractional pixel boundaries. This yields fuzzy edges. Honest question - how would layout managers position views in this scenario?

acqq 12y ago

> at the same time it's depressing to have this be the issue that makes fonts blurry Wait, have you actually seen blurry fonts on the iPhone 6 Plus? Do you know of any photograph which demonstrates them?

rsynnott 12y ago
Somebody with abnormally good eyesight probably could if they knew what they were looking for.
- acqq 12y ago
  I'm asking for a photo, even with a microscope. I'm really curious, because I still believe the difference can't be seen for the text sizes that are actually readable by humans that don't use magnifying glasses.

ridiculous_fish 12y ago

My understanding is that Android uses essentially the same strategy as iOS: don't attempt to support full resolution independence, but instead enumerate a set of supported DPIs. See the DisplayMetrics class: there's an enumeration of supported densities, and the 'density' property itself is noted as being a "gross" measure that is rounded to nice values, like 1.5. Of course extra space can absorbed into the screen size instead of its density. Android and iOS support this via their respective mechanisms, like autoresizing masks or autolayout on iOS, and I guess layout managers on Android. If you were to make a new device with unusual screen metrics, you have a few options for app compatibility. You could report an unusual density, and risk ugly antialiasing or pixel cracks. Alternatively, you could report an unusual size, and get bad layouts, where lots of apps will have UI elements overly small, and excessive unused space. Or you could compromise: report sane (but inaccurate) sizes and densities, and resample. This maximizes compatibility, with some quality and performance cost. (The idealized option is true resolution independence, where apps look great at any density and size. To my knowledge, nobody has achieved that.) I figure Apple realized that the iPhone 6+ would be very heavily reviewed, and so wanted to ensure that existing apps would work really well on it. That's what their scaling approach enables.

kllrnohj 12y ago
No, the DPI buckets are only for pre-baked assets (images, basically). Everything else is fully resolution independence. This was used for the original N7, for example, which didn't actually fit into either the MDPI or the HDPI buckets. It instead had a ratio of 1.33125, and yet everything but images are rendered unscaled.
- ridiculous_fish 12y ago
  Interesting. So what would happen if you drew, say, a 100 dip box on an N7? Would two edges just be blurry?
  - jordanthoms 12y ago
    On Android, drawing happens at directly on the output framebuffer, using pixel values. So If you were directly drawing a box, you'd have to convert 100dip into a px value and round it in some direction. But you wouldn't actually do that apart from in rare circumstances - instead, you'd create a View, size it to 100dip, and give it to a layout telling it to position it in say the center of the screen. When it's displayed, the layout manager will decide how big to actually draw it, taking the density into account. Android doesn't have the issues with pixel cracks etc you are talking about, since the views are all stored in Layout Managers which operate at the native device resolution and calculate the final positioning. So they can see that this element would be 10.5px, display it at 10px, and move the next element up by 1px so everything works out.
    - ridiculous_fish 12y ago
      I worked on autolayout, which does exactly what you describe: attempt to derive a pixel-aligned layout from abstract positioning rules. It was very difficult, so I'm skeptical that Android has found a way to just make "everything work out." The mathematics requires some sort of tradeoff. For example, say we have 10 views, alternating black and white, each 10 dips wide, packed abutting into a container of width 100 dips. At 1.33x scale, each view wishes to have 13.3 device pixels. How do Layout Managers solve this? 1. Round each view down to 13 pixels, and repeatedly "move the next element up" by 1 px? Then you must account for .3 * 10 = 3 unclaimed pixels at the end of your container. That's going to be quite visible. 2. Round views based on their fractional pixel position, i.e. seven views down to 13 pixels, and three views up to 14? Now your stripes have different widths, which can be visible (especially if they have high-frequency content), and can also cause a "creeping" effect when they animate, if their edges are rounded independently. 3. Don't round at all, and position views on fractional pixel boundaries. This yields fuzzy edges. Honest question - how would layout managers position views in this scenario?