On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <[email protected]> wrote:
> InterpolationQualityTest.java test fails consistently on windows 10 hence > adding it in the problemList. > > @shurymury Yes I was also very surprised to see this stable test fail. FWIW - when connecting by VNC the VM doesn't enumerate a display adapter in Device Manager - when connecting by RDP it lists an RDP software one It is quite funny actually, connecting via RDP when you were already logged in by VNC you can see it kill the VNC session and the "open" Device Manager quickly refreshes and removes the display adapter. BOTH seem to claim D3D is supported and enabled by default for 2D So right now I'm assuming this isn't an adapter on which we'd want to enable D3D and that's why the test fails. It will take a debugging build to understand what we see in start up that causes 2d to enable the D3D pipeline here. I am not sure it can be intentional as I have no recollection of that ever being something we would want to do. This is a blocker for using available VMs for testing. So until we figure it out then either we PL the test on windows, or we have to update all these lines below in the test to include -Dsun.java2d.d3d=false * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.xrender=false InterpolationQualityTest * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.xrender=True InterpolationQualityTest * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.d3d=false InterpolationQualityTest * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.d3d=True InterpolationQualityTest * @run main/othervm -Dsun.java2d.uiScale=1 InterpolationQualityTest BTW we probably need a better way of doing this because where a setting doesn't apply to a platform its a no-op So on both Windows and Linux we are running this 4 times in the "default" mode and once in another in non-default and then on Mac 5 times in the same default mode .. and not covering metal there FWIW. ------------- PR: https://git.openjdk.java.net/jdk/pull/5930
