I would not support your proposed 4th option. It's basically a partial
fix for the solution John mentioned as his third option.
Of the three John mentions, I favor either 1 or 2. I don't see a
compelling reason to guarantee thread-safety for Animation objects
(option 3), in which case the question becomes whether it is worth
having the play*/pause/stop methods do the runLater or require the user
to do it. The latter is more explicit, whereas the former is more
convenient.
What do others think?
-- Kevin
On 1/22/2024 8:46 AM, Jurgen Doll wrote:
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
