On Mon, 8 Nov 2021 22:32:59 GMT, Alexander Zuev <kiz...@openjdk.org> wrote:
>> I was able to reproduce this issue locally 2 times out of 100 runs on >> multi-monitor >> configuration. Both times due to the screen resolution change is so slow >> window got >> accidentally moved to the secondary screen by the display driver. >> Can not reproduce this bug with ATI card at all. >> Since there is nothing we can do to stop graphics driver from reassigning >> the window if it decides that promary monitor is not on at the moment the >> only way is to check if this has had happened and if so then we can not >> trust the test >> since we changing resolution of one display and window not getting resized >> because it is placed on another display and test should be skept. >> >> After that i ran this test locally about a thousand times on all platforms >> and has not seen the failure again. > > Alexander Zuev has updated the pull request incrementally with one additional > commit since the last revision: > > Check that setting the new display mode ended up with window > residing on the screen with resolution different than one it was before, > even if it the different display - window and components still have to > receive the resize event. Only skipping the iteration where that did not > happened instead of skipping the entire test. test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 158: > 156: Frame f = fsWin instanceof Frame ? > (Frame) fsWin : (Frame) fsWin.getOwner(); > 157: DisplayMode oldMode = > f.getGraphicsConfiguration().getDevice().getDisplayMode(); > 158: gd.setDisplayMode(dm1); probably it will be good to add a delay here? What is the longest display switch on the system where the bug is reproduced? a few seconds? ------------- PR: https://git.openjdk.java.net/jdk/pull/6186
