On Mon, 28 Apr 2025 17:32:09 GMT, Alexey Ivanov <aiva...@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
