4 ms·

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

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?
- kllrnohj 12y ago
  Android converts dips to pixels and rounds them at view inflation time, then works with pixels from then on. So the view would load its width of 10 dip, convert it to pixels and round it (13 pixels), and then measure itself to that size. The fractional part is completely lost, never to be seen again. So in that example there would indeed be 3 unclaimed pixels at the end of the container. For things like hairline borders you typically just specify that they are however many pixels wide. It's perfectly valid to say width=100dip, height=1px. You can mix & match at will. For the scenario where you just want to have a bunch of elements all fit on one row you usually just give them all the same weight and let the parent view divide up the space rather than saying parent=100, children each =10.

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?

kllrnohj 12y ago
Android converts dips to pixels and rounds them at view inflation time, then works with pixels from then on. So the view would load its width of 10 dip, convert it to pixels and round it (13 pixels), and then measure itself to that size. The fractional part is completely lost, never to be seen again. So in that example there would indeed be 3 unclaimed pixels at the end of the container. For things like hairline borders you typically just specify that they are however many pixels wide. It's perfectly valid to say width=100dip, height=1px. You can mix & match at will. For the scenario where you just want to have a bunch of elements all fit on one row you usually just give them all the same weight and let the parent view divide up the space rather than saying parent=100, children each =10.