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

[Jurgen Doll]

I've been delving into the usage of `aborted` and `inTimePulse` as  
mentioned by John and gleaned the following:

1. stop makes a best effort to abort the 'animation' if it is in the  
process of execution.
2. `aborted` and `inTimePulse` are reset with every pulse.

As to the options that John mentioned there's also a fourth:

Accept my original proposal of fixing the NPE which is a known problem and  
not worry about potential synchronization issues. I mean does it really  
matter if play, stop, or pause miss a beat due to synchronization, as the  
API does say this could happen. Furthermore it doesn't appear as though  
the animation code can be left in some strange inconsistent state as a  
result of this.

Jurgen


On Mon, 22 Jan 2024 17:58:20 +0200, John Hendrikx  
<john.hendrikx at gmail.com> wrote:

>
> This seems like a reasonable use case, and perhaps this was the original  
> intent of the "asynchronous call" documentation.
>
> The problem though is that the play/stop code does not seem to take into  
> account being called from a different thread (there are several  
> >synchronization issues when I delved into that code).
>
> So then there's a choice to make I think, either:
>
> - Disallow it completely, and have users wrap it into Platform.runLater()
> - Have play/stop do the wrapping itself
> - Make the methods thread safe by fixing the synchronization issues
>
> --John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240122/420b7998/attachment.htm>