On Mon, 24 Feb 2025 20:48:38 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> LOL, I think I may have said that :) However, perhaps the problem is not as
>> bad as I made it out to be. It's definitely true that any operation on a
>> floating point value may slightly nudge it away from a true snapped value
>> (somewhere in the 10th decimal place) and that this problem gets worse the
>> more operations you perform (ie. a HBox with 10.000 children will have a
>> worse error than one with only a few children).
>>
>> But there may be some middle ground possible here. As long as our layout
>> containers are aware that values returned from `computeMinWidth` etc are
>> only "near" snapped (meaning that if you round them to the nearest pixel,
>> you'll always get the right result), it should be fine -- one must take care
>> not to immediately call `ceil` or `floor` on these values. A thing we may
>> want to look into is how this is rendered on screen by the rendering layer;
>> does the rendering do additional work when values are near snapped, or do
>> they perform some rounding already anyway. I certainly never noticed these
>> small errors resulting in display artifacts.
>>
>> In any case, this is probably better addressed in a separate effort, and we
>> should probably write some guidelines first. I'm hoping to do some of this
>> with the space distributor PR.
>
> 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)
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976034201
