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