Hi Sergey, << One more thing which can improve the fix is to add "uiScale > 1.0" as an additional @run step to the tests, so these tests will fail before the fix even on common lowdpi(100%) systems. I have updated the webrev for the changes.
I will like to point out that, there are 9 test cases mentioned in the bug. But only 5 fail without fix. 4 tests pass because of following reasons. 1. SetShapeAndClickSwing.java, TranslucentJComboBox.java, TranslucentWindowClickSwing.java These tests don’t use the TranslucentWindowPainter as in these tests, the PerPixelTransparency which means the alpha of the window is set 1.0. Instead these tests change the window Opacity which is handled differently. So in these tests are scaled properly and don’t fail without the fix. 2. PerPixelTranslucentSwing.java This test passes as there is a problem in the way test is written. It is trying to check the transparency of window by comparing the robot picked color with Foreground color. But with HIDPI, the color value is picked from wrong location, but still the test passes as the picked value is not equal to the Foreground color. So we should check the color value with Background color. I was not very sure if I should fix this in this webrev, so I have created a separate issue for this. https://bugs.openjdk.java.net/browse/JDK-8190861. I will fix this test differently. So I have added the additional @run with uiScale in 5 tests that fail without fix and PerPixelTranslucentSwing.java as this is a test problem and this test fails when corrected Webrev: http://cr.openjdk.java.net/~pbansal/8164811/webrev.03/ Regards, Pankaj Bansal -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, November 7, 2017 1:45 PM To: Pankaj Bansal; Philip Race; Prem Balakrishnan Cc: swing-...@openjdk.java.net; 2d-dev@openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10] Review Request JDK - 8164811 : [hidpi]Tests fail with OpenGL Rendering Thanks for clarification. Looks fine. One more thing which can improve the fix is to add "uiScale > 1.0" as an additional @run step to the tests, so these tests will fail before the fix even on common lowdpi(100%) systems. On 06/11/2017 23:20, Pankaj Bansal wrote: > I am assuming you are talking about changes in UpdateWindow function in > TranslucentPainter. > I think it is doing exactly what was happening before the fix. It called > getBackBuffers and saved it in bb initially and then, If the update fails, > "done" will be false and it was calling getBackBuffers (true) to save the > buffer in bb everytime. So it was calling getBackBuffers() everytime the > update fails. Also the createBackBuffers function is creating backbuffer only > once and then just returning it if the width and height remains same. So when > I call update(getBackBuffers(false)), it will just return the backBuffers, > not create it. So this change has added a call to getBackBuffers, but without > it, I will have to add a check to see if the Image is BufferedImage or > VolatileImage to decide to transform the Graphics or not.
