JDK-8210547[linux] frame pacing etc.

[Michael Zucchi]

On 3/10/25 03:34, Thiago Milczarek Sayão wrote:
> I confess I did not understand much about the problem.
>
> Is it about variable refresh rates?
> If I think a message _VARIABLE_REFRESH is received on the Notify event.
>
No, I'm pretty sure I would have mentioned that if it was!

> Or
> https://docs.gtk.org/gdk3/class.FrameClock.html
>
I came across that but as far as I can tell that's only for gtk widget's 
rendering pipeline which isn't relevant, apart from maybe an example of 
how to do it.

> I also did an EGL version in place of GLX:
> https://github.com/openjdk/jfx/pull/1381
>
Fair enough.  I may see if that makes any difference another time, 
although the eglSwapBuffers() man page isn't really any different to the 
glX one and afaict from a quick look at the mesa source it all ends up 
at the same place internally.
> -- Thiago
>

It's a couple of things.

I experience the bug mentioned in the title with a trivial test 
programme (first email to list) and default settings - I get uncapped 
pulses/second on multiple AMD systems - ~600/s on a laptop and ~2000/s 
on a desktop.  It's just burning cpu and battery for no good reason.  
It's probably due to a bug in mesa or amdgpu exposed due to the way 
javafx swaps around gl contexts.

It's about incorrect assumptions about the behaviour of the GLX api - 
i.e. that glXSwapBuffers() on a double-buffered window will block 
waiting for vsync in the same way Direct3D's Present() with the provided 
flags does.  This is not correct[1], and even when GLX does throttle it 
wont necessarily throttle where expected so that 'vsyncHint()' has any 
meaning.  The man page offers the correction: glFinish(), but that 
doesn't work if executed per-window.

It's also about just poor timing code / api in general. 
gdk_threads_add_timeout_full's man page:

    Note that timeout functions may be delayed, due to the processing of
    other event sources. Thus they should not be relied on for precise
    timing. After each call to the timeout function, the time of the
    next timeout is recalculated based on the current time and the given
    interval (it does not try to “catch up” time lost in delays).

There is some messy code to try to account for that looseness when vsync 
(the default) is requested (vsyncHint() and associated), but not 
otherwise.  But even without that the api has such limited precision it 
just doesn't work very well.  i.e. setting prism.vsync=false 
javafx.animation.pulse=60 wont give you even a jittery 60/s pulse rate - 
it will be a jittery higher one.  It seems very low hanging fruit to fix.

  Z

[1] 
https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251003/1f858e55/attachment.htm>