Animation enhancements

Nir Lisker nlisker at
Tue Sep 11 16:00:12 UTC 2018

So the questions remain about embedded animations. If an animation has a
"starting" and it is embedded, should it pause a sequential animation? This
is the same problem with the the cycle synchronous events. For parallel,
does it delay only itself so that the animations are not parallel anymore?
Or, we could ignore this event when embedded. Do you have any other idea?

On Tue, Sep 11, 2018 at 6:50 PM Brian Hudson <brian.r.hudson at>

> Async: started, cycleStarted, cycleEnded, ended, paused, resumed
> A "starting" event would have to be synchronous to work as I described.
> The other "-ing" events probably aren't useful an cause the complications
> you describe.
> On Tue, Sep 11, 2018 at 10:11 AM Nir Lisker <nlisker at> wrote:
>> So the "-ed" events are synchronous? That is, in case of "started", the
>> animation needs to wait until the event handling finished and then start.
>> In the case of "starting", the animation would start and call the event
>> handler asynchronously (like "finished" does now).
>> Synchronous events can be problematic because they interfere with the
>> running of the animation. A "cycleStarting" (for example) handler will need
>> to suspend the animation somehow before each cycle for an unknown duration
>> (because it can't know what you put in the handler code). This can be done
>> in practice via something like Future, but I'm skeptical about how much
>> this would fit with the current animation semantics.
>> There is a case for "starting" though, which is that it doesn't interfere
>> with a running animation, and that it can be used as a
>> "prepare-then-start", as you said. But what happens when the animation is
>> embedded in a sequential and parallel transitions?
>> I agree that other "-ed" events are not that useful. We can discuss a
>> "prepare-then-start" mechanism.
>> On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson <brian.r.hudson at>
>> wrote:
>>> starting: Indicates that the animation is about to start. This is the
>>> last opportunity to change an aspect of the animation that cannot be
>>> changed once the animation has started. PathTransition duration for example.
>>> started: The animation has started.
>>> The "-ed" actions are really what I've had a need for, other than
>>> "starting" I can't really think of use cases for the other "-ing" events
>>> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker <nlisker at> wrote:
>>>> Hi Brian,
>>>> Thanks for the input. How is "starting" different from "started" etc.?
>>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson <brian.r.hudson at>
>>>> wrote:
>>>>> I would love to see "Animation needs more events" resolved [1].
>>>>> Maybe following events: started, paused, resumed, cycleStarted,
>>>>> cycleEnded,
>>>>> stopped/ended? These additional life cycle events would allow me to do
>>>>> some
>>>>> things with animations/transitions that I've been struggling to do.
>>>>> There may even be use cases events for starting, pausing, resuming,
>>>>> cycleStarting, cycleEnding, stopping/ending.
>>>>> [1]:

More information about the openjfx-dev mailing list