Hi Michael,
Welcome to the openjfx-dev list. We've not ever been able to reproduce
this on any of our systems. It seems likely that it is specific to
certain graphics drivers. We do all our testing on Ubuntu Linux and
Oracle Linux (which is based on RHEL), so it's also possible we are
testing with different drivers even for the same card.
If you have a reliable patch for the bug, you can submit a PR although
we will need to find a way to test it. See the CONTRIBUTING [1]
guidelines for what you will need to do in order to contribute.
Ambarish or Lukasz might have some additional comments.
Thanks.
-- Kevin
[1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
On 9/22/2025 8:21 AM, Kevin Rushforth wrote:
Redirecting to openjfx-dev which is the right list to discuss
technical issues such as this.
-- Kevin
On 9/20/2025 8:02 PM, Michael Zucchi wrote:
Morning list!
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. 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. 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.
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).
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.
With some guidance/pointers I can look further if it would be of use
to the project.
Regards,
Michael Z
[1] https://bugs.openjdk.org/browse/JDK-8210547
[2] gentoo, liunux 6.12.36, AMD Ryzen 4700U APU.
[3] slackare64-current linux 6.12.29, Ryzen 3900X, Radeon HD7970.
--
Group g = new Group(new Text("Hello"));
g.setTranslateX(100);
g.setTranslateY(100);
root.getChildren().setAll(g);
Transition anim = new Transition() {
double arg = 0;
{
setCycleCount(INDEFINITE);
setCycleDuration(Duration.seconds(1));
}
@Override
protected void interpolate(double frac) {
g.setRotate(arg++);
}
};
anim.play();
