Hi John, the threading restrictions are now removed. What I mean by those seemingly contradictory stratements is the following: This change doesn't make Animation inherently thread-safe, so if you configure the animation on thread A, you can't just call play() on thread B and expect it to work. What the change *does* allow you to do, is configure the animation on background thread A, and then call play() on the same background thread.
On Thu, Jan 25, 2024 at 12:19 PM John Hendrikx <john.hendr...@gmail.com> wrote: > > 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
