Rate of embedded animations

Kevin Rushforth kevin.rushforth at oracle.com
Tue Jan 7 23:13:32 UTC 2020

A rate in a "parent" transition should probably override the rate in a 
child Animation. There are a couple ways to do it, and it sounds like it 
doesn't really implement it right.

1. The public rate property values of child Animations within a parent 
Transition are ignored, but not updated. As long as the implementation 
is consistent in ignoring the rate property from the child Animation, 
this seems like a fine solution and is consistent with other properties 
where one property overrides another without modifying it.

2. Setting a rate on the parent Transition actually modifies the child 
node. This can work, but has more issues. What happens if you set the 
rate of the parent tansition and then set the rate of a child animation? 
What if you bind to the rate of a child animation?

-- Kevin

On 1/1/2020 1:04 PM, Nir Lisker wrote:
> Hi,
> As part of my work in the animations package I've come across an undefined
> spec. Is the rate of an animation that is embedded in a Parallel/Sequential
> transition inherited and overridden by its parent?
> If I have an animations with a rate of 1 and a parent with a rate of 2, and
> I add the animation to the parent, does the rate property change from 1 to
> 2 (generating a change/invalidation event etc.)? Then, should any
> subsequent changes to the parent's rate trigger a change in the child's
> rate?
> The implementation is a bit messy in this regard. The rate and currentRate
> values exist in both Animation and its ClipEnvelope, which is the source
> for a couple of bugs. For example, changing the rate of a
> ParallelTransition changes the child's ClipEnvelope's rate and currentRate,
> but only the animation's currentRate (and not rate). Is it supposed to be
> this way?
> What is clear is that it's not possible to change the rate of the embedded
> animation directly.
> The docs do not talk about the rate of an embedded animation (they do talk
> about the node property though).
> - Nir

More information about the openjfx-dev mailing list