On Wed, 22 Jul 2026 03:10:23 GMT, Sergey Bylokhov <[email protected]> wrote:
>> When we use XOR mode to clear the drawn content in Metal pipeline, it is >> leaving some traces. >> We noticed similar issue when Metal pipeline was under development: >> [JDK-8251167](https://bugs.openjdk.org/browse/JDK-8251167). But the fix is >> not complete and we still see some traces. Using uiScale 1.0 with >> contrasting background and foreground color reveals this not so easily >> noticeable issue. >> >> In case of Metal XOR mode is implemented using shaders and we are using an >> interpolated position passed from Vertex shader to determine the current >> position of fragment/pixel. We also add magic offsets to line vertices in >> MTLRenderer.DrawLine() and it can cause different approximations while >> calculating the interpolated position. >> >> Because of this we end up in mismatch between the pixel from which we are >> reading the content and the pixel to which we are writing. Instead of using >> interpolated position we should use the rasterized position present in >> fragment shader to pick the appropriate pixel. When we use rasterized >> position mismatch doesn't happen and XOR draw clears the content properly. >> >> We need this change in both `frag_col_xorMode` and `frag_txt_xorMode` >> shaders. Gradient and texture paint shaders are no-op in case of XOR as they >> use software loops, so no change is made in those shaders. Regression test >> is added only for color shader as mathematically i was able to reproduce >> issue only for color shader, but product fix is needed in case of text >> shader also. >> >> If we use rasterized position to pick pixels we don't need fix done under >> [JDK-8251167](https://bugs.openjdk.org/browse/JDK-8251167), so that change >> is also reverted. >> >> Code update is tested in CI and no regressions seen. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/shaders.metal line > 710: > >> 708: float4 pos4 = float4(in.position, 0.0, 1.0); >> 709: out.position = transform.transformMatrix*pos4; >> 710: out.orig_pos = in.position; > > Does vert_txt_lcd is also affected? I don't think we should bother about it. LCD text is disabled on Mac. The only reason for this shader is to provide a bit bolder fonts at the cost of great performance loss. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31981#discussion_r3629067723
