Ooops, forget it. It falls back to software rendering, because the correct parameter is GLX_NONE not None.
Em sex., 3 de out. de 2025 às 12:55, Thiago Milczarek Sayão < [email protected]> escreveu: > 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 >> >>
