[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Animation enhancements
From:       Nir Lisker <nlisker () gmail ! com>
Date:       2018-09-11 16:00:12
Message-ID: CA+0ynh-GieO_LZB6ggGNGFYrxnkag=RH4sK-ryLeDwFujYo+eQ () mail ! gmail ! com
[Download RAW message or body]

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@gmail.com>
wrote:

> 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@gmail.com> 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@gmail.com>
>> 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@gmail.com> 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@gmail.com>
>>>> 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]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>>>
>>>>
[prev in list] [next in list] [prev in thread] [next in thread]