Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes! #6186

Closed
wants to merge 6 commits into from

Conversation

azuev-java
Copy link
Member

@azuev-java azuev-java commented Nov 1, 2021

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.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes!

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6186/head:pull/6186
$ git checkout pull/6186

Update a local copy of the PR:
$ git checkout pull/6186
$ git pull https://git.openjdk.java.net/jdk pull/6186/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6186

View PR using the GUI difftool:
$ git pr show -t 6186

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6186.diff

…n't receive all resizes!

Made sleep() method always sleep at least the requested amount
Checking if window got accidentally reassigned to another graphics device,
skipping test if so.
Removed test from the problem list.
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Nov 1, 2021

👋 Welcome back kizune! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

@openjdk openjdk bot commented Nov 1, 2021

@azuev-java this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8169468
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk openjdk bot added merge-conflict rfr labels Nov 1, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 1, 2021

@azuev-java The following label will be automatically applied to this pull request:

  • client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the client label Nov 1, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Nov 1, 2021

Webrevs

@@ -178,6 +189,10 @@ public void run() {
});
} catch (Exception ex) {}

if (skipTest.get()) {
// Skipping test because graphics driver switched window to another screen
return;
Copy link
Contributor

@prrace prrace Nov 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test isn't about multi-mon .. it is about full screen.
If the window doesn't go full screen on the display we expect that's odd.
Are you saying it went FS on one display and then jumped ?
Can't we make the test more robust about it going on the display we expect OR pivot the test to verifying on the display that went FS ?

Copy link
Member Author

@azuev-java azuev-java Nov 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying it went FS on one display and then jumped ?

That is exactly what happened and only in this case the test were failed - obviously, because the window was on a secondary display and resize was happening on the primary so window has not got any events about resize. I added a lot of debug information to the native code but after that i ran test for hours non stop and it does not reproduce - i guess it is all due to the timings. You see, when we changing resolution the physical display goes offline (at least on my system with NVidia card) meaning status LED goes from green to amber, then it goes green again with the new resolution set. If request to get full screen windows from GD comes at that exact moment the window might be placed on a secondary display which does not change. I do not know how to force OS not to reassign window to another display in this case.

Copy link
Member

@mrserb mrserb Nov 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the scenario above what will happen if the window is jumped from one screen to another? Will it be full screen or it will be in the normal mode? Which (old or new) graphics device will report that the window is full screen on it? I guess we should move the window back to the old device in full-screen mode, or we should move the window to the new device but in the normal mode, in both cases, the resize event should be generated, isn't it?

Copy link
Member Author

@azuev-java azuev-java Nov 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the scenario above what will happen if the window is jumped from one screen to another? Will it be full screen or it will be in the normal mode? Which (old or new) graphics device will report that the window is full screen on it? I guess we should move the window back to the old device in full-screen mode, or we should move the window to the new device but in the normal mode, in both cases, the resize event should be generated, isn't it?

It opens up as a full screen window on the secondary display, i can't check which device reports it because when i add debug output i can not reproduce the failure. If two displays have different resolution then moving window from one GD to another it should generate the resize event on both window and the component inside it.

Copy link
Member

@mrserb mrserb Nov 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then you can check that the window jumped to a different screen and the size counter should not be increased if the requested mode and the size of the new screen are the same. You do not need to skip the whole test in this case. But it also looks like a bug that the window is jumped to the other screen and is not returned back.

Copy link
Member Author

@azuev-java azuev-java Nov 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then you can check that the window jumped to a different screen and the size counter should not be increased if the requested mode and the size of the new screen are the same.

Ok, done exactly that.

But it also looks like a bug that the window is jumped to the other screen and is not returned back.

Yes but that might be the issue with the Windows itself and i do not think there is anything that can be done on this test level.

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.
@@ -151,9 +153,21 @@ public void run() {
System.err.printf("----------- Setting DM %dx%d:\n",
dm1.getWidth(), dm1.getHeight());
try {
Frame f = fsWin instanceof Frame ? (Frame) fsWin : (Frame) fsWin.getOwner();
DisplayMode oldMode = f.getGraphicsConfiguration().getDevice().getDisplayMode();
gd.setDisplayMode(dm1);
Copy link
Member

@mrserb mrserb Nov 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

@azuev-java azuev-java Nov 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, i think 2 seconds will be enough.

mrserb
mrserb approved these changes Nov 16, 2021
@openjdk openjdk bot removed merge-conflict rfr labels Nov 16, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 16, 2021

@azuev-java This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes!

Reviewed-by: serb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added ready rfr labels Nov 16, 2021
@azuev-java
Copy link
Member Author

@azuev-java azuev-java commented Nov 16, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Nov 16, 2021

Going to push as commit b0a463f.

@openjdk openjdk bot closed this Nov 16, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Nov 16, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 16, 2021

@azuev-java Pushed as commit b0a463f.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client integrated
3 participants