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

[Kevin Rushforth]

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.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/21e457c2/attachment-0001.htm>