RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to incorrect pixel color and wrong window bounds

[Sergey Bylokhov]

On Fri, 2 Dec 2022 18:13:43 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 61:
>> 
>>> 59:         final Frame wGreen = new Frame();
>>> 60:         wGreen.setBackground(Color.GREEN);
>>> 61:         wGreen.setUndecorated(true);
>> 
>> Why did you make that frame undecorated? I think the decoration was one of the reasons why the bug was reproduced.
>
> When testing on Win10, observed that for a decorated frame the title bar is retained in full screen mode unlike some of the other applications (eg. Chrome and IDE in full screen mode). 
> 
> When I checked the Javadocs for [setFullScreenWindow(Window w)](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsDevice.html#setFullScreenWindow(java.awt.Window)), it states that - _"It is unspecified and platform-dependent how decorated windows operate in full-screen mode. For this reason, it is recommended to turn off the decorations in a Frame or Dialog object by using the setUndecorated method."_  
> 
> For the above reasons and to aid testing the pixel-color across full-screen window without having to account for different platform specific title bar sizes, the frame was set as undecorated.

You just uncover this bug https://bugs.openjdk.org/browse/JDK-7019055 referenced in the test, and one of the reasons why the specification is state what it states. SO it is better to not make the frame decorated but instead exclude it based on the current graphics device, OGL/D3D vs win32(or something like that)

>> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 89:
>> 
>>> 87:             device.setFullScreenWindow(wRed);
>>> 88:             sleep();
>>> 89:             testWindowBounds(device.getFullScreenWindow().getBounds(), wRed);
>> 
>> You changed the code
>> from:
>>    comparing the bounds of the display mode and the bounds of the window
>> to:
>>    comparing the bounds of the window and the bounds of the window
>> I do not think it is the right thing to do.
>
> @mrserb I noticed that the difference in actual size vs display mode dimensions is because the actual size is scaled down by the device's current scale unlike display mode. This can be resolved by running the test at uiScale=1.

The usage of "device.getDefaultConfiguration().getBounds()' looks better.

-------------

PR: https://git.openjdk.org/jdk/pull/11462