Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thread-safe interaction between Animation and AbstractPrimaryTimer #1349

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

mstr2
Copy link
Collaborator

@mstr2 mstr2 commented Jan 24, 2024

This PR ensures that internal interactions between Animation and AbstractPrimaryTimer 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 with AbstractPrimaryTimer will be encapsulated in the new nested class AnimationPulseReceiver, which also deduplicates redundant interactions with AbstractPrimaryTimer.

For example, repeatedly calling start() and stop() in quick succession may require just a single interaction with AbstractPrimaryTimer 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 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).


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

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

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 24, 2024

👋 Welcome back mstrauss! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Mar 13, 2024

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@bridgekeeper
Copy link

bridgekeeper bot commented May 9, 2024

@mstr2 This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant