On Wed, 7 Jun 2023 20:13:55 GMT, Alisen Chung <ach...@openjdk.org> wrote:
>> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes >> more time on macOS 13 than on previous macOS version. So the test failure is >> triggered by the lack of synchronisation. >> When you added displayChanged() call you introduced some kind of delay and >> the problem stopped happening but it is still present. I do not think any >> changes are required in JDK but the test definitely needs some >> modifications. >> In particular I believe the test must check the state of the frame only when >> the corresponding `window state changed` event is received. > >> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes >> more time on macOS 13 than on previous macOS version. So the test failure is >> triggered by the lack of synchronisation. When you added displayChanged() >> call you introduced some kind of delay and the problem stopped happening but >> it is still present. I do not think any changes are required in JDK but the >> test definitely needs some modifications. In particular I believe the test >> must check the state of the frame only when the corresponding `window state >> changed` event is received. > > I did some testing and I think that without the delay, when the frame moves > from iconified to maximized states, the second windowStateChanged event never > comes (first being iconified -> normal, second being normal -> maximized), so > the test will not pass even if we only check state of the frame on a > windowStateChanged event. > > Why do you think no changes are required in the JDK? Shouldn't there be some > synchronization needed when calling the native deminiaturize and maximize > functions in CPlatformWindow? @alisenchung @mrserb After reading through the discussion, I think the fix on native side rather than on Java might work better here. I was revisiting a Tray Icon issue which had similar sync problem when I was trying to get updated scale value on Java side by using a DisplayChangedListener [Details here - [PR#8441](https://github.com/openjdk/jdk/pull/8441#issuecomment-1121345834)] and there were multiple events occurring back to back. When I had a hard-coded delay set on Java side, the update to tray icon worked fine. I think this is a similar case where introducing a delay solves the issue. But since hard-coded delay is not the ideal solution probably triggering/ calling the required piece of code after everything is updated on native side is the way to go (event/message-driven). Handling the code on Window's native code with the help of windows messaging event solved the Trayicon problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1581538514
