Thread-safe interaction between Animation and AbstractPrimaryTimer #1349
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR ensures that internal interactions between
Animation
andAbstractPrimaryTimer
only occur on the FX application thread.All changes to observable state will remain instantly visible for the calling thread. However, internally, interactions with
AbstractPrimaryTimer
are posted to the FX thread if necessary. This is not an unsurprising change, since the callback from the FX thread was always occuring at an unspecified time in the future.To make this work,
AbstractPrimaryTimer::pause/resume/nanos
will have to be synchronized to ensure field visibility across threads. In the Animation class, interactions withAbstractPrimaryTimer
will be encapsulated in the new nested classAnimationPulseReceiver
, which also deduplicates redundant interactions withAbstractPrimaryTimer
.For example, repeatedly calling
start()
andstop()
in quick succession may require just a single interaction withAbstractPrimaryTimer
in the future (if we ended up in the running state), or no interaction at all (if we ended up in the stopped state).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.With this proposal,
play()
can be called on a background thread, and the behavior of theAnimation
class remains the same. If you're readinggetStatus()
after callingplay()
, you will always see that the animation is currently running (even if internally, the animation hasn't yet been added to the primary timer).Progress
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1349/head:pull/1349
$ git checkout pull/1349
Update a local copy of the PR:
$ git checkout pull/1349
$ git pull https://git.openjdk.org/jfx.git pull/1349/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1349
View PR using the GUI difftool:
$ git pr show -t 1349
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1349.diff