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
