RFR: 8335748: Rippling of frame on scrolling

Lukasz Kostyra lkostyra at openjdk.org
Mon Nov 24 11:57:58 UTC 2025


On Thu, 20 Nov 2025 11:37:53 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> **Issue:** 
> With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.
> 
> **Cause:**
> vsync is not enabled for metal pipeline.
> 
> **Fix:** 
> 1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
> 2. Synchronize the access to offline render target texture.
> 2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
> 2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
> 2.3 NSLock is created to synchronize the acess
> 2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.
> 
> **Verification:**
> 1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
> 2. Test no issue observed when moving window among screens.
> 3. General sanity testing of UI.
> 
> **Test:**
> A unit or system test is not possible for this scenario.

modules/javafx.graphics/src/main/native-glass/mac/GlassLayerMTL.m line 155:

> 153:     // {
> 154:     //     The texture is locked, either being created/destroyed or being encoded into BlitEncoder
> 155:     //     hence the frame could be dropped.

Just a curiosity question, but would we have a possibility to wait for the texture to become available to us instead of dropping the frame?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1978#discussion_r2556015087


More information about the openjfx-dev mailing list