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