RFR: 8358820: Allow interpolation outside of range [0,1]

[Michael Strauß]

On Sun, 15 Jun 2025 05:34:17 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> JavaFX unnecessarily restricts interpolation in the following ways:
>> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
>> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
>> 
>> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Beziér interpolation function.
>> 
>> This PR includes the following changes:
>> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
>> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
>> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
>> 
>> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
>> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/region/BorderImageSlices.java line 62:
> 
>> 60:         Objects.requireNonNull(endValue, "endValue cannot be null");
>> 61: 
>> 62:         if (t == 0 || equals(endValue)) {
> 
> `==` on floating point could produce unexpected results since there's +0 and -0. Here it doesn't seem to matter because it's an optimization, but I see more of these in the new code, so might be worth double checking.

+0 and -0 seem to be equal when using the `==` operator:

double a = 0.0;
double b = -0.0;
System.out.println(a == b); // prints "true"
System.out.println(a < b); // prints "false"
System.out.println(a > b); // prints "false"


If the sign is relevant, one must use `Double.compare`:

double a = 0.0;
double b = -0.0;
System.out.println(Double.compare(a, b)); // prints "1"
System.out.println(Double.compare(b, a)); // prints "-1"

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2148839136