Hi Craig,
I don't see your bug reports. I tried looking them up with both the
subject line and ID. I'll forward your email to the those responsible
for managing bugreport.java.com to see if they know why the bugs weren't
created in our system.
In the mean time, I'll file the MetalTexture bug report myself. I can
reproduce it using the instructions in this email, so that is sufficient.
I can file the accessibility JNI local references leak bug tomorrow.
We'll need a test case in order to address it. Do you have one?
-- Kevin
On 10/29/2026 8:57 AM, Craig Raw wrote:
Hi,
I'm the developer of Sparrow Wallet, a JavaFX desktop app. I'd like to draw
attention to two bugs I've submitted through bugreport.java.com, since
neither has appeared in JBS yet, and the first will be encountered fairly
often in the wild.
1. [macOS, Metal] Window renders blank when larger than 4096 pixels
Submitted today, reference b3da673d-82e0-42a1-953a-f6b3c4209ae9
With the Metal pipeline, the default on macOS from JavaFX 27, a window
larger than 4096 pixels in either dimension draws nothing and stays white.
MTLResourceFactory.createPresentable() calls checkTextureSize() with the
window's render size, and that limit is clamped to
PrismSettings.maxTextureSize, which defaults to 4096. The Metal device
reports 16384. On a Retina display this affects any window wider than about
2048 points, so maximized windows on 5K and 6K displays are blank. ES2
creates its swap chain without this check, so the same window renders with
-Dprism.order=es2.
My users started reporting this within hours of my first release on JavaFX
27.0.1. The submission includes a short standalone reproducer: run any
window with -Dprism.maxTextureSize=1024 on a Retina Mac. The affected code
is unchanged on master. As a workaround I'm shipping
-Dprism.maxTextureSize=8192, which solves the issue.
2. Accessibility callbacks leak JNI local references
Submitted 2026-09-15, reference 13f748e3-6142-4fd0-bde0-8d1d994251a2
The native accessibility callbacks (mac/GlassAccessible.m,
win/GlassAccessible.cpp) don't delete the JNI local references they create.
Every accessibility read therefore retains MacVariant/WinVariant objects
until the app exits. I reproduced it outside my app with JavaFX 26: each
read of a 100-control window's accessibility tree retained 306 MacVariant
and 106 long[] objects. On macOS 26, Spotlight alone activates JavaFX
accessibility (JDK-8391459), so this affects users who don't use a screen
reader.
Could someone look these submissions up? I'm happy to provide more detail
or test fixes.
Thanks,
Craig Raw
