On Tue, 25 Nov 2025 00:33:41 GMT, notzed <[email protected]> wrote: >> As discussed on the mailing list. >> >> OpenGL requires an explicit glFinish() to synchronise with the video >> refresh. The current usage is incorrect and against the specification. >> This patch calls glFinish() after all windows have been drawn following a >> pulse. > > notzed has refreshed the contents of this pull request, and previous commits > have been removed. The incremental views will show differences compared to > the previous content of the PR. The pull request contains one new commit > since the last revision: > > JDK-8210547 synchronise with OpenGL after the last window is presented
prism.vsync=false behaves visually the same as it currently does because double buffering isn't enabled via glXSwapIntervalSGI(). i.e it runs at roughly 62.5fps by default. One caveat is that glFinish() will pause the CPU to wait for the GPU and that may have throughput impacts, or it may be desirable to avoid over-buffering. glFinish() is the only way to sync the cpu with the video card[1] and honour the expectations of prism (i.e. that presentation with 'vsync supported' is throttled by the frame-rate) in the same way directx is. And the only place it makes sense is immediately after glSwapBuffers(). But it can't be done per-window otherwise all windows are displayed round-robin with the frame rate. The problematic point is the QuantumTooklit.vsyncHint() call which itself causes unthrottled pulses - they are only throttled in practice by Presentable.present(). vsyncHint() also seems to not be used anywhere to actually indicate vsync, it just fires another pulse after rendering is finish which just upsets the pulse regularity. I tried a number of variations over a couple of weeks and this was by far the simplest I could come up with but i'm open to suggestions. Note [1] also suggests a 'high precision timer' should be used for frame timing instead of vsync, and gdk_timeout used by the x11 backend is definitely not suitable for this purpose, even a simple ScheduledExecutorService (as used by monocle and headless) is far more accurate. But discovering accurate frame-rates is problematic (they should be rational but the gtk api's don't support that, and gtk4 and wayland has it's whole own idea of animation timing) and they can change at runtime or even across screens. I do have another patch to enable nanosecond (or it could be microsecond) frame times and a floating point animation rate ... but that is far far more intrusive. [1] https://wikis.khronos.org/opengl/Swap_Interval#GPU_vs_CPU_synchronization ------------- PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3573400736
