On X11GLFactory.c Around line 92 on setGLXAttrs, add:
glxAttrs[index++] = GLX_CONFIG_CAVEAT; glxAttrs[index++] = None; It does seem to fix the problem. Em sex., 3 de out. de 2025 às 00:03, Michael Zucchi <[email protected]> escreveu: > 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 > >
