JDK-8210547[linux] Uncontrolled framerate, general frame sync/over-calculating animations
Kevin Rushforth
kevin.rushforth at oracle.com
Mon Sep 22 15:21:29 UTC 2025
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();
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250922/62abc6fe/attachment-0001.htm>
More information about the openjfx-dev
mailing list