On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> interpolatable. Consider the following `Background`, which describes the
>> background of a `Region`:
>>
>>
>> Background {
>> fills = [
>> BackgroundFill {
>> fill = Color.RED
>> }
>> ]
>> }
>>
>>
>> Since backgrounds are deeply immutable, changing the region's background to
>> another color requires the construction of a new `Background`, containing a
>> new `BackgroundFill`, containing the new `Color`.
>>
>> Animating the background color using a CSS transition therefore requires the
>> entire Background object graph to be interpolatable in order to generate
>> intermediate backgrounds.
>>
>> More specifically, the following types will now implement `Interpolatable`.
>>
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>>
>> ## Interpolation of composite objects
>>
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each
>> of these classes is an aggregate of `double` values, which are combined
>> using linear interpolation. However, many of the new interpolatable classes
>> comprise of not only `double` values, but a whole range of other types. This
>> requires us to more precisely define what we mean by "interpolation".
>>
>> Mirroring the CSS specification, the `Interpolatable` interface defines
>> several types of component interpolation:
>>
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated
>> by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t
>> = 0` produces the start value, and `t = 1` produces the end value. This
>> interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the
>> intermediate component value is equal to the start value for `t < 0.5` and
>> equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start
>> list has fewer elements than the target list, the...
>
> Michael Strauß has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains 48 additional
> commits since the last revision:
>
> - Merge branch 'master' into feature/interpolatable
> - remove StyleConverter.WithReconstructionSupport
> - fix line separators
> - StyleableStringProperty should be transitionable
> - non-interpolatable values should always transition discretely
> - only call get() when necessary
> - add more documentation
> - replace reconstruction annotation with interface
> - interpolate integers in real number space
> - replace StyleConverter.SupportsDeconstruction interface with annotation
> - ... and 38 more: https://git.openjdk.org/jfx/compare/38e61055...2337ca98
I did some manual testing on the current iteration of this PR, including
transitions between multiple pseudoclasses (including the back transitions).
From an aesthetics point of view that looked good! Easing modes were honored, I
didn't see any glitches, final states were correct. So I'm not sure there's a
big need to outdo the CSS spec here, considering this is a CSS-only feature
where end values are static, and it's not programmatically accessible API. (If
the latter is needed, one can always just refrain from using CSS transitions
and do everything manually).
I've also had a look at the proposed implementation.
Looks like the important decision is how/where the currently running transition
is being tracked. John's suggestions seem valid, but I don't see how they
really simplify things compared to the current proposal. I'd say the private
`mediator` fields in the stylable Property classes are ok the way they are
currently proposed, they are updated whenever the Property changes.
A logically sound alternative may be to let `Node` track transitions, but I
doubt we want to add more details there when the issue can be solved with
private implementation fields in the Property implementations.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325184408
