A modern programming language that makes developers happier.

kotlinlang

Why compose PaddingValues is not a Value class?
I was wondering since padding values represent padding in non-negative dp, can't we just make it a value class. The class stores padding in shorts (half floats).

The largest value type (long) is 64 bits. A PaddingValues is four floats. A float is 32 bits, so you need 128 bits total. So there's not enough room in a value class to store the full PaddingValues. 

Even if you remove the sign because negative padding is invalid, you've saved four bits total (one per float). Still, 124 bits is too big.

1733277536552.png

<@U01DGH70L5C> Thanks :+1:. As you might have not read I mentioned half floats not floats.

A non-negative float is not the same thing as a half float. You'd lose a ton of precision by packing a 32 bit float into only 16 bits. Converting an 11 bit mantissa to base 10, you'd only get around 3-4 significant figures in your half float.

<@U01DGH70L5C> Correct me if I'm wrong, but we're dealing with dp (density-independent pixels) and not actual pixels. Given that, I don't believe we need such a high level of precision (i.e., converting from float32 to float16) to represent a dp value effectively. For most UI elements, the precision offered by float16 should be more than sufficient for representing dp values without noticeable loss in visual accuracy.

With a typical 16 bit half-float, around the number ~1000dp (6.25" at 160dpi) you’re down to a precision of ~0.5dp. At ~2000dp (12.5") you’re down to a precision of 1dp. There are devices today where ~0.5dp error would be more than a pixel; definitely noticeable, and that’s before considering animation where even subpixel error could cause jitter instead of smooth motion

useful tool to play with IEEE floats here: <https://evanw.github.io/float-toy/>