4 ms·

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, s

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.

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.