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

[Andy Goryachev]

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

>> Come to think of it, most the issues here are caused by using functions like `floor` and `ceil`.  It might be an idea to change these functions to bias them slightly towards rounding to the closest value, instead of always doing a straight up `floor` or `ceil`.
>> 
>> For example, let's say I calculate a size as `3.0000001`; ceiling this (with snapSize) to `4` is quite ridiculous; obviously `3` was intended, but the ceiling function won't care.  But what if we subtracted a value (assuming we're dealing with pixels of course, which the `snap` functions are)? We could bias it slightly towards the correct value by using something ridiculously small like 1/10000th of a pixel. For example:
>> 
>> `3.0000001` - 1/10000th of a pixel = `2.9999`. Ceiling this value yields the intended `3`.  We could work much safer with near snapped values, as there is much less risk of a one ulp difference being dramatically amplified by floor/ceil functions.
>
>> good point!
>> 
>> This is exactly the reason for the code in ScaledMath:71
>> 
>> ```
>> return Math.ceil(d - Math.ulp(d)) / scale;
>> ```
> 
> Yeah, but I think we may want to subtract more than just 1 ulp.  A one ulp difference can be created after any operation (like add/subtract).  Do two of these without resnapping, and the difference will be >1 ulp)

I think you are onto something here.  It almost feels like we shouldn't be doing ceil/floor at all, rounding to the closest pixel instead.

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

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