RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4]

[Andy Goryachev]

On Fri, 28 Feb 2025 21:35:30 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> In theory, all these calculations end up being used by the layoutChildren() which always (?) snap the values.
>> 
>> So the question is whether this small error gets accumulated enough to shift the result to a wrong value.  Given a typical number of children (<1000) and screen sizes (<10000), we might conclude that it's unlikely, since
>> 
>> `Math.ulp(1000 * 10_000.0) = 1.862645149230957E-9`
>> 
>> which is much smaller than the distance between pixels even at 1000% scale.
>
> That's absolutely true, however this can change quickly when large values are added or subtracted to/from small values, or when division or multiplication gets involved.  So I'd say its relatively safe to do simple calculations with near snapped values, but one must be careful with functions like `ceil` and `floor` as they can amplify tiny floating-point errors due to their discontinuous nature.  For example, if take a snapped `spacing` and add a snapped `left` and `right` margin, then call ceil on the result, it could go like this:
> 
>              1.99999999999999 +
>              4.00000000000001 +
>              4.00000000000001 =
>             10.00000000000001 -> ceil -> 11 (instead of the expected 10)

good point!

This is exactly the reason for the code in ScaledMath:71

return Math.ceil(d - Math.ulp(d)) / scale;

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976043283