<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Redirecting to openjfx-dev which is the right list to discuss
technical issues such as this.<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 9/20/2025 8:02 PM, Michael Zucchi
wrote:<br>
</div>
<blockquote type="cite" cite="mid:e66e87f7-1eca-44ee-8189-2dce95cfbe0b@gmail.com">
<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" moz-do-not-send="true">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> </blockquote>
<br>
</body>
</html>