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

[Kevin Rushforth]

If you mean the changes proposed in Draft PR 
https://github.com/openjdk/jfx/pull/1349 those are too-intrusive for 
where we are in JavaFX 22. I see no chance that we will get agreement on 
the approach and be able to finish the code review and CSR in the next 4 
business days.

If we later get general agreement that the changes you propose are 
needed, we could consider them for JavaFX 23. For 22, I think we're down 
to either leaving it as is or reverting the thread checks and wrapping 
the implementation in a runLater.

I don't think having the state change be asynchronous if you run it on a 
thread other than the application thread will be an issue. And, as I 
pointed out earlier, it is documented that the animation might not start 
or stop right away.

-- Kevin


On 1/25/2024 11:07 AM, Michael Strauß wrote:
> Hi Kevin,
>
> have you considered my proposal, which is basically the same approach:
> it uses runLater internally to dispatch the interaction with
> AbstractPrimaryTimer (instead of trying to make AbstractPrimaryTimer
> work under concurrent access).
>
> But from the point of view of the caller, the API works just as it
> worked before: all state changes of the Animation class are instantly
> visible, there is no surprising change as it would be with what you're
> currently proposing.
>
> With my proposal, play() can be called on a background thread, and the
> behavior of the Animation class remains the same. If you're reading
> getStatus() after calling play(), you will always see that the
> animation is currently running (even if internally, the animation
> hasn't yet been added to the primary timer).
>
>
> On Thu, Jan 25, 2024 at 6:30 PM Kevin Rushforth
> <kevin.rushforth at oracle.com> wrote:
>> And that's why the "be careful" option is not a satisfying solution.
>>
>> Let's proceed with the option to change the implementation of play/pause/stop/start to do the work in a runLater, and change the docs accordingly. It's the only feasible option for JavaFX 22 (other than "do nothing"), and I also think it is a good choice. If we later want to evolve it for thread-safety, which I'm not convinced that we do, we can consider that for a future release.
>>
>> -- Kevin