On Sat, 26 Sep 2026 07:49:49 GMT, Sergey Bylokhov <[email protected]> wrote:
>> Phil Race has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 6986565 > > test/jdk/sun/java2d/SunGraphics2D/PolyVertTest.java line 55: > >> 53: * @bug 4678208 4771101 6328481 6588884 8198613 >> 54: * @summary verify the pixelization of degenerate polylines and polygons >> 55: * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.opengl=True >> PolyVertTest -hwonly > >>-Dsun.java2d.opengl=True > > This will restore the mode dropped by the > https://bugs.openjdk.org/browse/JDK-8198613 in this test. > >>-Dsun.java2d.uiScale=1 > > Do we actually support HiDPI, it seems like completely dropping its > validation in 2d tests? If it is hard to make it work for UI frames, why is > it changed for offscreen rendering as well? Just in some robot tests where it will help in getting stable results and the test isn't invalidated by doing it. Regarding problems with OpenGL, if that resurfaces we can look to revert, but with the instability of the test fixed, we can give it another chance as that surely didn't help. > test/jdk/sun/java2d/SunGraphics2D/PolyVertTest.java line 630: > >> 628: >> 629: public static void testScreen() throws Exception { >> 630: EventQueue.invokeAndWait(PolyVertTest::createUI); > > Why this "jump" on EDT is needed? The code uses only AWT components so it > should work on the main as well, or does it produce any garbage on the screen? A couple of times (not recently) there has been discussion that since AWT started to use LW that it is safest to use this pattern and so is helpful for test stability. > test/jdk/sun/java2d/SunGraphics2D/PolyVertTest.java line 728: > >> 726: return; >> 727: } >> 728: render((Graphics2D) g); > > I have pointed out for the previous similar fix that rendering to the > component synchronously and validating the results after exactly one repaint > is not equivalent to showing the frame then waiting until it is repainted > (possibly a few times) and then making a check. Trying to grab the screen right after the first paint is an occasional cause of failing to grab the right pixels. The rendering, even if repainted ought to end up the same. There's no reason the test is only valid on first paint. That would be a bug itself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32992#discussion_r4138853727 PR Review Comment: https://git.openjdk.org/jdk/pull/32992#discussion_r4138811572 PR Review Comment: https://git.openjdk.org/jdk/pull/32992#discussion_r4138828581
