JDK-8210547[linux] Uncontrolled framerate, general frame sync/over-calculating animations

[Kevin Rushforth]

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(); 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250922/74ebcd38/attachment.htm>