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.hendr...@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
