JDK-8210547[linux] frame pacing etc.

[Thiago Milczarek Sayão]

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 <
thiago.sayao at gmail.com> 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 <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/e8df707d/attachment.htm>