<div dir="ltr">Ooops, forget it. It falls back to software rendering, because the correct parameter is GLX_NONE not None.<div><br></div></div><div dir="ltr"><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 3 de out. de 2025 às 12:55, Thiago Milczarek Sayão <<a href="mailto:thiago.sayao@gmail.com" target="_blank">thiago.sayao@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">On X11GLFactory.c<div><br></div><div>Around line 92 on <span style="font-family:"JetBrains Mono",monospace;font-size:9.8pt;background-color:rgb(25,26,28);color:rgb(188,190,196)">setGLXAttrs</span>, add:</div><div><div style="background-color:rgb(25,26,28);color:rgb(188,190,196)"><pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt">glxAttrs[index++] = GLX_CONFIG_CAVEAT;<br>glxAttrs[index++] = None;</pre></div></div><div>It does seem to fix the problem.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 3 de out. de 2025 às 00:03, Michael Zucchi <<a href="mailto:notzed@gmail.com" target="_blank">notzed@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <div>On 3/10/25 03:34, Thiago Milczarek
      Sayão wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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">
      <div dir="ltr">
        <div>Or</div>
        <div><a href="https://docs.gtk.org/gdk3/class.FrameClock.html" target="_blank">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">
      <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" target="_blank">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">
      <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 href="https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml" target="_blank">https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml</a><br>
    <br>
  </div>

</blockquote></div>
</blockquote></div></div>