On Fri, 28 Feb 2025 21:52:36 GMT, John Hendrikx <jhendr...@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
