<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css">body { font-family:'Calibri'; font-size:13px}</style>
</head>
<body><div><big>I've been delving into the usage of `aborted` and `inTimePulse` as mentioned by John and gleaned the following:</big></div><div><big><br></big></div><div><big>1. stop makes a best effort to abort the 'animation' if it is in the process of execution.</big></div><div><big>2. </big><big>`aborted` and `inTimePulse` are reset with every pulse.</big></div><div><big><br></big></div><div><big>As to the options that John mentioned there's also a fourth:</big></div><div><big><br></big></div><div><big>Accept my original proposal of fixing the NPE which is a known problem and not worry about potential </big><big>synchronization issues. </big><big>I mean does it really matter if play, stop, or pause miss a beat due to </big><big>synchronization, as the API does say this could happen. </big><big>Furthermore it doesn't appear as though the animation code can be left in some strange inconsistent state as a result of this.</big></div><div><big><br></big></div><div><big>Jurgen<br></big></div><div><big></big><br></div><div>On Mon, 22 Jan 2024 17:58:20 +0200, John Hendrikx <john.hendrikx@gmail.com> wrote:<br></div><br><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex">
<p>This seems like a reasonable use case, and perhaps this was the
original intent of the "asynchronous call" documentation.</p>
<p>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).</p>
<p>So then there's a choice to make I think, either:</p>
<p>- Disallow it completely, and have users wrap it into
Platform.runLater()<br>
- Have play/stop do the wrapping itself<br>
- Make the methods thread safe by fixing the synchronization
issues</p>
<p>--John</p></blockquote></body></html>