<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <font face="DejaVu Sans">Morning list!<br>
      <br>
      I hit the above bug[1] a little while ago while using a Transition
      for timing on a couple of GNU/Linux systems [2,3].  Basically it
      runs flat-chat because each interpolation call makes changes which
      triggers a new render pass which then re-runs the animators if
      they're active, which retriggers another render pass and so on. 
      Trivial example that demonstrated is below.  If you set a specific
      frame-rate in the constructor then it doesn't occur.  </font><font
      face="DejaVu Sans">None of the related system properties seem to
      have any effect.  Tracing through the code I couldn't see how this
      doesn't always happen with X11/OpenGL, plus there seems to be a
      bunch of stale/unfinished frame throttling code that never gets
      run.</font><font face="DejaVu Sans">  I also noticed that
      gdk_timer was used for frame timing, but this is documented as not
      being suitable for this task - it lacks suitable resolution and
      must be reset each call guaranteeing drift.  And in any event
      timing unlinked from the display will never be accurate.  <br>
      <br>
      I developed a small patch to use GLX_SGI_video_sync to synchronise
      to the actual video frame-rate.  It's probably hooked into the
      wrong place but i'm not very familiar with the code and couldn't
      find much documentation on the internals of prism and quantum
      toolkit; I've attached it as a matter of interest.  With this
      patch enabled multiple windows will render smoothly matching the
      video frame rate exactly and the animation calculations are only
      invoked once per frame apart from wrap-around of cyclic animations
      (I've only tested with simple scenes).<br>
      <br>
      The main drawback is added latency for low-frame rate monitors
      (I've tested with a system that can do anything from 25 to 150),
      and the 'animation now timestamp' is calculated ad-hoc rather than
      syncing to the expected presentation time.  Having to call
      glXMakeContext extra times isn't very cheap either, but it's
      already being called a lot.<br>
      <br>
      With some guidance/pointers I can look further if it would be of
      use to the project.<br>
      <br>
      Regards,<br>
       Michael Z<br>
      <br>
    </font><font face="DejaVu Sans">[1] <a
        class="moz-txt-link-freetext"
        href="https://bugs.openjdk.org/browse/JDK-8210547">https://bugs.openjdk.org/browse/JDK-8210547</a><br>
      [2] gentoo, liunux 6.12.36, AMD Ryzen 4700U APU.<br>
      [3] slackare64-current linux 6.12.29, Ryzen 3900X, Radeon HD7970.</font><br>
    <font face="DejaVu Sans"><br>
      --<br>
    </font><font face="DejaVu Sans">            Group g = new Group(new
      Text("Hello"));<br>
                  g.setTranslateX(100);<br>
                  g.setTranslateY(100);<br>
                  root.getChildren().setAll(g);<br>
                  Transition anim = new Transition() {<br>
                      double arg = 0;<br>
      <br>
                      {<br>
                          setCycleCount(INDEFINITE);<br>
                          setCycleDuration(Duration.seconds(1));<br>
                      }<br>
      <br>
                      @Override<br>
                      protected void interpolate(double frac) {<br>
                          g.setRotate(arg++);<br>
                      }<br>
                  };<br>
                  anim.play();</font>
  </body>
</html>