<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 3/10/25 03:34, Thiago Milczarek
Sayão wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAP_wu=1QbnrZ4ydvuC_U7HZgcZ-OLFU4iLh==Z+Pa2DQuXsSg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I confess I did not understand much about the
problem.
<div><br>
</div>
<div>Is it about variable refresh rates?</div>
<div>If I think a message _VARIABLE_REFRESH is received on the
Notify event.</div>
<div><br>
</div>
</div>
</blockquote>
No, I'm pretty sure I would have mentioned that if it was!<br>
<br>
<blockquote type="cite"
cite="mid:CAAP_wu=1QbnrZ4ydvuC_U7HZgcZ-OLFU4iLh==Z+Pa2DQuXsSg@mail.gmail.com">
<div dir="ltr">
<div>Or</div>
<div><a href="https://docs.gtk.org/gdk3/class.FrameClock.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.gtk.org/gdk3/class.FrameClock.html</a><br>
</div>
<div><br>
</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAAP_wu=1QbnrZ4ydvuC_U7HZgcZ-OLFU4iLh==Z+Pa2DQuXsSg@mail.gmail.com">
<div dir="ltr">
<div>I also did an EGL version in place of GLX:</div>
<div><a href="https://github.com/openjdk/jfx/pull/1381"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jfx/pull/1381</a><br>
</div>
<div><br>
</div>
</div>
</blockquote>
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.
<blockquote type="cite"
cite="mid:CAAP_wu=1QbnrZ4ydvuC_U7HZgcZ-OLFU4iLh==Z+Pa2DQuXsSg@mail.gmail.com">
<div dir="ltr">
<div>-- Thiago</div>
<div><br>
</div>
</div>
</blockquote>
<br>
It's a couple of things.<br>
<br>
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.<br>
<br>
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.<br>
<br>
It's also about just poor timing code / api in general.
gdk_threads_add_timeout_full's man page:
<blockquote>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).<br>
</blockquote>
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.<br>
<br>
Z<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml">https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml</a><br>
<br>
</body>
</html>