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ß <michaelstr...@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
