On Mon, 24 Nov 2025 11:54:26 GMT, Lukasz Kostyra <[email protected]> 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?
Waiting could cause a crash, in situation when the lock is already acquired for
destroying / creating the texture.
In that case the size of current CAMetalDrawable and size of newly created
texture could mismatch.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1978#discussion_r2558702078
