On Fri, 28 Feb 2025 21:48:54 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> good point! >> >> This is exactly the reason for the code in ScaledMath:71 >> >> return Math.ceil(d - Math.ulp(d)) / scale; > > 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) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976048373
