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

Jump to bottom

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

Closed
wants to merge 6 commits into from
+24 −8
Closed

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

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
cfd1efa
8169468: NoResizeEventOnDMChangeTest.java fails because FS Window did…
azuev-java Nov 1, 2021
da325c4
Check that setting the new display mode ended up with window
azuev-java Nov 8, 2021
06b5864
Added speel for 2 seconds after setting new display mode.
azuev-java Nov 10, 2021
b8ff723
Resolve merge conflict
azuev-java Nov 16, 2021
4f60b69
Merge branch 'master' into JDK-8169468
azuev-java Nov 16, 2021
35eda9b
Resolve merge conflicts
azuev-java Nov 16, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 test/jdk/ProblemList.txt
View file
Open in desktop
@@ -497,7 +497,6 @@ java/awt/xembed/server/RunTestXEmbed.java 7034201 linux-all
java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsDocModalTest.java 8164473 linux-all
java/awt/im/memoryleak/InputContextMemoryLeakTest.java 8023814 linux-all
java/awt/Frame/DisposeParentGC/DisposeParentGC.java 8079786 macosx-all
java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java 8169468 macosx-all
java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java 8213120 macosx-all

java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java 7099223,8274106 macosx-aarch64,linux-all,windows-all
29 test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java
View file
Open in desktop
@@ -1,5 +1,5 @@
/*
* Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved.
* Copyright (c) 2007, 2021, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -26,7 +26,6 @@
* @bug 6646411
* @summary Tests that full screen window and its children receive resize
event when display mode changes
* @author Dmitri.Trembovetski@sun.com: area=Graphics
* @run main/othervm NoResizeEventOnDMChangeTest
* @run main/othervm -Dsun.java2d.d3d=false NoResizeEventOnDMChangeTest
*/
@@ -40,11 +39,14 @@
import java.awt.Graphics;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Point;
import java.awt.Rectangle;
import java.awt.Window;
import java.awt.event.ComponentAdapter;
import java.awt.event.ComponentEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.util.concurrent.atomic.AtomicBoolean;

public class NoResizeEventOnDMChangeTest {
public static void main(String[] args) {
@@ -102,6 +104,7 @@ private static void testFSWindow(final GraphicsDevice gd,
final Window fsWin)
{
System.out.println("Testing FS window: "+fsWin);
final AtomicBoolean skipTest = new AtomicBoolean(false);
Component c = new Canvas() {
@Override
public void paint(Graphics g) {
@@ -152,6 +155,13 @@ public void run() {
dm1.getWidth(), dm1.getHeight());
try {
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.

// Check if window is placed on this gd
Rectangle screenBounds = gd.getDefaultConfiguration().getBounds();
Rectangle windowBounds = fsWin.getBounds();
if (!screenBounds.contains(new Point(windowBounds.x, windowBounds.y))) {
System.out.println("Window got moved to another screen, test not valid");
skipTest.set(true);
}
r1.incDmChanges();
r2.incDmChanges();
} catch (IllegalArgumentException iae) {}
@@ -166,6 +176,7 @@ public void run() {
fsWin.removeComponentListener(r1);
c.removeComponentListener(r2);
}

try {
EventQueue.invokeAndWait(new Runnable() {
public void run() {
@@ -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.

}
System.out.printf("FS Window: resizes=%d, dm changes=%d\n",
r1.getResizes(), r1.getDmChanges());
System.out.printf("Component: resizes=%d, dm changes=%d\n",
@@ -191,10 +206,14 @@ public void run() {
}

static void sleep(long ms) {
try {
Thread.sleep(ms);
} catch (InterruptedException ex) {}
long targetTime = System.currentTimeMillis() + ms;
do {
try {
Thread.sleep(targetTime - System.currentTimeMillis());
} catch (InterruptedException ex) {}
} while (System.currentTimeMillis() < targetTime);
}

static class ResizeEventChecker extends ComponentAdapter {
int dmChanges;
int resizes;