RFR: 8352149: open/test/jdk/java/awt/Frame/MultiScreenTest.java fails [v2]

[Abhishek Kumar]

On Mon, 28 Apr 2025 17:32:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> The test doesn't work on Linux either. The problem on Linux is that there are too many graphics configurations are returned.
>>> 
>>> On my Fedora Linux 42 with two monitors, `gs[j].getConfigurations()` returns an array of length **176**.
>>> 
>>> It could be the reason why the loop divides the number of configurations: `gc.length / 2`.
>>> 
>>> In the end, this loop creates **176** window and a thread for each of the windows. This hangs GNOME shell completely. A few times, I was able to kill the `java` process via SSH connection, but it doesn't always help, and it still takes quite a while to get back to responsive UI.
>>> 
>>> I'm sure this problem was discussed somewhere… (I'll search for that discussion later.) We should limit testing to default configurations only.
>>> 
>>> As for Windows, the test could be usable on Windows and macOS if you remove replace `< gc.length / 2` with `< gc.length` as @kboulanou suggested initially. On Windows and macOS, there's usually only one configuration returned from `gs[j].getConfigurations()` for each screen.
>> 
>> 
>> I tested on Ubuntu 22.04 and don't find any issues. `gs[j].getConfigurations()` returns an array of length **120**, it took sometime to get back to responsive UI but the waiting time is not that much.
>> Seems creating another **38** windows and a thread for each window causing more overhead in your case.
>> 
>> I agree that `gc.length/2` is to reduce the number of frames created on the screen to avoid the hang.
>> If the testing doesn't require so many frames to create then it can be reduced for linux as well (may be 5 or something based on the `gc.length` returned from `gs[j].getConfigurations().
>> 
>> Since the original bug was raised for Solaris, I suggested to drop the testing for Windows and Mac.
>> 
>> As per the bug description, `The picture is: No images or few images showed up on the second screen, but the first screen is messed up with images and text strings everywhere.`, my assumption is **creating multiple frames with images and text strings may be the requirement (although it's not clearly mentioned)**.
>> 
>> @aivanov-jdk  If we replace `< gc.length / 2` with `< gc.length` on Windows and Mac, we will have less frames to test. I agree this will make the test to run but will it add any value to it ?
>
>> I tested on Ubuntu 22.04 and don't find any issues. `gs[j].getConfigurations()` returns an array of length **120**, it took sometime to get back to responsive UI but the waiting time is not that much. Seems creating another **38** windows and a thread for each window causing more overhead in your case.
> 
> I'm pretty sure it depends on hardware: how many configurations are returned and how easy the OS and CPU can handle lots of threads.
> 
>> I agree that `gc.length/2` is to reduce the number of frames created on the screen to avoid the hang. If the testing doesn't require so many frames to create then it can be reduced for linux as well (may be 5 or something based on the `gc.length` returned from `gs[j].getConfigurations().
> 
> I don't see how such a huge number of windows can possibly improve testing.
> 
> I'd say testing the default configuration which is the current one for the screen should be enough.
> 
>> Since the original bug was raised for Solaris, I suggested to drop the testing for Windows and Mac.
>> 
>> As per the bug description, `The picture is: No images or few images showed up on the second screen, but the first screen is messed up with images and text strings everywhere.`, my assumption is **creating multiple frames with images and text strings may be the requirement (although it's not clearly mentioned)**.
> 
> I do not think so.
> 
>> @aivanov-jdk If we replace `< gc.length / 2` with `< gc.length` on Windows and Mac, we will have less frames to test. I agree this will make the test to run but will it add any value to it ?
> 
> As it looks, the test isn't valuable in its current state either way.
> 
> I don't think we'll be able to reproduce the original problem, yet it may be possible.
> 
> [The bug description](https://bugs.openjdk.org/browse/JDK-4312921#descriptionmodule) states,
> 
>> No images or few images showed up on the second screen, but the first screen is messed up with images and text strings everywhere. Those wrong text strings and images stay on the first screen even after the screenTest application terminated. It seems not like the repaint problem since the images were drawn to the wrong place at the first beginning.
> 
> Then [Phil says in his comment](https://bugs.openjdk.org/browse/JDK-4312921?focusedId=12554259&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12554259),
> 
>> The DGA docs are VERY misleading … indicate that the file descriptor returned from `dga_draw_devfd` is per device. This is not always so as we discovered.
> 
> Th...

@aivanov-jdk In that case, test can be modified to run for default configuration for all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2837868859