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
