>
> What happens if you set the rate of the parent transition and then set the
> rate of a child animation?
>
What if you bind to the rate of a child animation?
There is already some code that touches this in the Animation's rate
property:
public void invalidated() {
final double newRate = getRate();
if (isRunningEmbedded()) {
if (isBound()) {
unbind();
}
set(oldRate);
throw new IllegalStateException("Cannot set rate of embedded
animation while running.");
}
isRunningEmbedded checks for a parent animation that is not STOPPED. That
means that the rate of a child animation can only change while the parent
is stopped, but it is ignored (the child's ClipEnvelope's rate is updated
to the parent's rate instead).
Binding to the rate property is never an issue, but it does give
meaningless results since the rate is ignored. Binding the rate property
itself will cause it to be unbinded.
If we go with option 1, which is almost the current situation, there is
only some cleanup needed when it comes to the relation between the
Animation's rate and its ClipEnvelope's rate.
If we go with option 2, we can eliminate the duplication of rate in the
Animation and the ClipEnvelope (though ClipEvenope to Animation is somewhat
like a peer to a Node, which duplicates the values as well, so maybe we
want that?). The children's rate will always be the parent's rate. In this
case the above code should probably be modified to account for STOPPED
parents as well. A bound rate property will be unbinded and setting it will
be either ignored or throw an exception.
I'll note that currentRate is eliminated from the ClipEnvelope in the fix
I'm working on, but as it's read-only, it's a different story.
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.
Which other properties? delay, autoReverse, and cycleCount all work
separately on the parent and child. For example, if both parent and child
have autoReverse = true and cycleCount = 2, the animation will play
forwards, backwards, forwards, backwards, so both are taken into account.
On Wed, Jan 8, 2020 at 1:14 AM Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:
> 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
>
>
