On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
> Adds code to trigger a scene update when a Window is restored > > This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and > https://bugs.openjdk.org/browse/JDK-8146479 First an errata: I wrote earlier that notifyRepaint is only called on Linux when restoring a window. I was wrong, it's also called for EXPOSE events. Anyway, I can reproduce this bug on all three platforms. JavaFX won't paint to a minimized window. This suggests to me that when we transition out of the minimized state someone needs to call `entireSceneNeedsRepaint`. The glass code on Windows and Linux both issue `notifyRepaint` which eventually calls `entireSceneNeedsRepaint`. The Mac code never issues `notifyRepaint` and `entireSceneNeedsRepaint` isn't called. I can tweak the Mac code to call `notifyRepaint` to match Windows and Linux but presumably that won't fix the bug. It looks like some other bit of state gets out of whack due to the way the system refuses to paint while minimized. I have no idea whether `updateSceneState` is the appropriate call to get the system back into sync or not. I have verified that on all platforms `updateSceneState` is not being called when the window is restored. I'll also note that with this test case there's no focus ring or flashing caret that needs to be drawn which seems to make a difference. Reproducing this on macOS 15 is complicated by some weirdness going on under the hood. The address of the main screen changes unexpectedly. This causes glass to send `notifyMoveToAnotherScreen` which resets a whole lot of state. This can happen when I first move a window or when I iconify and de-iconify it. Depending on the "Minimize windows to application icon" setting this can happen every time I de-iconify or only the first time. I have no idea why the system keeps generating new NSScreen objects on an ongoing basis. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2779336390
