JDK-8210547[linux] frame pacing etc.

[Thiago Milczarek Sayão]

Just out of curiosity, I compiled the EGL version. Here:
https://github.com/tsayao/jfx/releases/tag/test-egl

It does seem to have a difference in frame rate.



Em sex., 3 de out. de 2025 às 00:03, Michael Zucchi <notzed at gmail.com>
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251003/412e1e4e/attachment.htm>