HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE

[John Hendrikx]

Hi Michael,

I'm not quite sure I see the point of this change.  The PR did not 
remove the threading restrictions on play/stop.

I'm also confused by the seemingly contradictory statements:

- this proposal does NOT allow Animation.play/stop/etc. to be "called on 
any thread"
- It merely removes the requirement that these methods must be called on 
the FX thread

What does that mean exactly?

Also, I think the "asynchronous" wording may apply to property changes 
and action handlers that run at time index 0.  These surely won't be ran 
synchronous when calling "play", and I'm pretty sure they never were.

--John

On 24/01/2024 22:39, Michael Strauß wrote:
> Note: this proposal does NOT allow Animation.play/stop/etc. to be
> "called on any thread" as mentioned in JDK-8324658 [0].
>
> It merely removes the requirement that these methods must be called on
> the FX thread, but this doesn't make the class inherently thread-safe.
> That is an important distinction to proposals that call for posting
> the play/stop calls directly to the FX thread.
>
>
> [0] https://bugs.openjdk.org/browse/JDK-8324658
>
>
> On Wed, Jan 24, 2024 at 10:30 PM Michael Strauß <michaelstrau2 at gmail.com> wrote:
>> Here's another option, which I have implemented as a proof of concept [0]:
>>
>> The play/stop/etc. methods are currently specified to be
>> "asynchronous". This language should be removed, such that the methods
>> will be implied to execute synchronously from the point of view of the
>> caller (like every method that doesn't specify anything to the
>> contrary).
>>
>> All changes to observable state will remain instantly visible for the
>> calling thread. However, internally, interactions with
>> AbstractPrimaryTimer are posted to the FX thread if necessary. This is
>> not an unsurprising change, since the callback from the FX thread was
>> always occuring at an unspecified time in the future.
>>
>> To make this work, AbstractPrimaryTimer::pause/resume/nanos will have
>> to be synchronized to ensure field visibility across threads.
>> In the Animation class, interactions with AbstractPrimaryTimer will be
>> encapsulated in the new nested class AnimationPulseReceiver, which
>> also deduplicates redundant interactions with AbstractPrimaryTimer.
>> For example, repeatedly calling start() and stop() in quick succession
>> may require just a single interaction with AbstractPrimaryTimer in the
>> future (if we ended up in the running state), or no interaction at all
>> (if we ended up in the stopped state).
>>
>>
>> [0] https://github.com/openjdk/jfx/pull/1349