On Fri, 4 Sep 2026 22:27:26 GMT, Marius Hanl <[email protected]> wrote:
>> I think it would best to ignore this in this PR (it was broken before, it is >> still now), and instead make a follow-up PR that switches round -> rint >> (this was sort of the plan already) as round behaves poorly with our current >> sentinel `Double.MAX_VALUE` or anything else that wouldn't fit in a `long`. >> >> In that same PR, we can remove the `ulp` in the ceiling code, as removing an >> `ulp` from `Double.MAX_VALUE` severely changes the value with no recourse. >> A constant epsilon (that is far smaller than `Double.MAX_VALUE`) would just >> be ignored, ie: >> >> Double.MAX_VALUE - 0.0000001 == Double.MAX_VALUE >> >> But >> >> Double.MAX_VALUE - ulp(Double.MAX_VALUE) >> Double.MAX_VALUE >> >> (with `>>` meaning a lot smaller) > > @hjohn just pinging you, as you deprecated it and you might be more aware > about potential special cases / problems. The problem is primarily in how `round` deals with large values. It basically just converts a double to a long, meaning `Double.MAX_VALUE` is completely lost. That's not intended since FX uses doubles for layout, and we never said there'd be some arbitrary cut-off at `Long.MAX_VALUE` due to how we implemented render scaling. `rint` also deals better with other doubly things (like NaN and infinities). `round` will just collapse those (ie. NaN becomes 0, hiding real bugs). The `Double.MAX_VALUE` -> `Long.MAX_VALUE` thing can also be annoying when unit testing, and makes the test seem wrong. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2278#discussion_r3940077239
