<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    I would not support your proposed 4th option. It's basically a
    partial fix for the solution John mentioned as his third option.<br>
    <br>
    Of the three John mentions, I favor either 1 or 2. I don't see a
    compelling reason to guarantee thread-safety for Animation objects
    (option 3), in which case the question becomes whether it is worth
    having the play*/pause/stop methods do the runLater or require the
    user to do it. The latter is more explicit, whereas the former is
    more convenient.<br>
    <br>
    What do others think?<br>
    <br>
    -- Kevin<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 1/22/2024 8:46 AM, Jurgen Doll
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:op.2hyjkih80ae2rt@admin-pc">
      
      <style type="text/css">body { font-family:'Calibri'; font-size:13px}</style>
      <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><br>
      </div>
      <div>On Mon, 22 Jan 2024 17:58:20 +0200, John Hendrikx
        <a class="moz-txt-link-rfc2396E" href="mailto:john.hendrikx@gmail.com"><john.hendrikx@gmail.com></a> 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>
    </blockquote>
    <br>
  </body>
</html>