RFR: 8276058: Some swing test fails on specific CI macos system
Phil Race
prr at openjdk.java.net
Wed Oct 27 16:42:21 UTC 2021
On Wed, 27 Oct 2021 12:42:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:
> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
> It was seen from the logs that we have color mismatch in these tests.
>
> For example, in PressedIcon test, we had following log
>
> ----------System.out:(1/75)----------
> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
> ----------System.err:(13/842)----------
> java.lang.RuntimeException: Colors is different for scale=1!
> at PressedIconTest.main(PressedIconTest.java:97)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
>
> and JInternalFrame test, we had
> ----------System.err:(15/939)----------
> FRAME_COLOR Red: 255; Green: 200; Blue: 0
> Pixel color Red: 55; Green: 55; Blue: 55
> java.lang.RuntimeException: Internal frame is not correctly dragged!
> at bug8069348.main(bug8069348.java:96)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
>
> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>
> The awt tests that are failing seems to have different root cause and will be handled separately.
test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 88:
> 86: robot.waitForIdle();
> 87: Color color = robot.getPixelColor(centerX-10, centerY-10);
> 88:
So the problematic pattern is a mouse move to the location from which you subsequently capture a pixel?
I can see how on a compositing window manager that might be an issue as the cursor is part of the window
whereas on old X11 it isn't part of the root window .. but why isn't this ALWAYS an issue on macOS ?
I wonder how many other tests have the same issue ?
And is an offset of 10 enough ? Its a bit arbitrary and cursors could be a larger shape or different orientation ..
test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 93:
> 91: BufferedImage img = robot.createScreenCapture(screen);
> 92: javax.imageio.ImageIO.write(img, "png", new java.io.File("image.png"));
> 93:
Are we writing the image or any other type of file in the CWD in other tests ?
Shouldn't this use TESTCLASSES or something like that ?
test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 107:
> 105: throw new RuntimeException("Colors is different for scale=2!");
> 106: }
> 107: System.out.println("Test Passed");
Hmm .. the test tags are
* @run main/othervm PressedIconTest
* @run main/othervm -Dsun.java2d.uiScale=2 PressedIconTest
What if the default scale is 2 ?
Or on Windows it could be 1.25 ?
I don't see anything that restricts this test to macOS.
If you are going to explicitly test for 1 and 2 here, shouldn't we explicitly set it ?
And if you aren't then the test here needs to do something based on the actual scale.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6140
More information about the client-libs-dev
mailing list