I forgot to bring up https://bugs.openjdk.java.net/browse/JDK-8200206,
which is also relevant to this discussion. The solution to that one is
probably allowing only 1 parent, similar to the scenegraph policy. That
will avoid parent animations fighting over the state of common children
animations.
On Sat, Jan 11, 2020 at 3:08 AM Nir Lisker <nlis...@gmail.com> wrote:
> 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
>>
>>
