Could the flashing problem be related to the timing problem described in JDK-8209329 <https://bugs.openjdk.java.net/browse/JDK-8209329>?
I have noticed occasional red flashes using Metal, which I suspect are caused by trying to render uninitialized data. (I’m guessing that the red is a debugging aid provided by Apple. Previously, they used yellow.) > On May 29, 2021, at 12:22 AM, Alexey Ushakov <a...@openjdk.java.net> wrote: > > On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov <a...@openjdk.org> wrote: > >> Set black color for underlying window background to perform correct blending >> operations in metal with window surface destination > > Looks like the second option won't work because the result of blending will > still be mixed with the NSWindow background color. Also, I tried several more > approaches (Use only rgb blending, make the layer opaque). They helped to > resolve the test issues but caused regressions in other areas (SwingSet2 tree > for example). So, now I think that the only working solution is presented > here (to set the background color of the window) > >> Yes, looks like we have the flashing problem back. It seems more serious >> than this particular bug. >> We have two options here: >> >> 1. accept this behavior for metal (It would be not a problem if we implement >> JDK-8265445) >> 2. reimplement all the composing operations via shaders instead of using >> metal blending rules > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4206 >
