JDK-4929542 : PIT: Regression Test - D3DTranslucency.java fails on Solaris
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    solaris_8,solaris_9,solaris_10,windows_2000 solaris_8,solaris_9,solaris_10,windows_2000
  • CPU: x86,sparc
  • Submitted: 2003-09-29
  • Updated: 2005-10-19
  • Resolved: 2005-10-19
Related Reports
Duplicate :  
JDK-4934197 - REGRESSION: Regression-test sun/java2d/DirectX/D3dTranslucency.java fails on spa
Duplicate :  
JDK-6258131 - Regression test D3dTranslucency.java fails with solaris-sparc on Tiger,Mustang
Duplicate :  
JDK-5005364 - Regression-test sun/java2d/OpenGL/XformVolatile.java fails
Description
The regression test D3DTranslucency.java located under sun/java2d/DirectX fails when running on Solaris 8/9. This failure is reproducible only on the PIT build and the test passes on all the previous builds. The test passes on Win32 platforms. 

I am not quite sure whether this test must be executed on Solaris. However, when the actual color used in the translucent image is (255, 0, 0) the screen captured buffered image contains the color (254, 0, 0) and hence the test reports it as a failure. 

I tested this on the following PIT build:
java version "2d-jcg-sparc-01-2003-09-28.tiger"
Java(TM) 2 Runtime Environment, Standard Edition (build 2d-jcg-sparc-01-2003-09-28.tiger)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b21, mixed mode)
Comments
EVALUATION There was a duplicate bug filed (see 6258131) which was fixed in Mustang. Basically the D3DTranslucency testcase was modified so that it allows for a +/- 1 pixel variance in the tested pixel value. We are aware that there is some chance for minor rounding errors when the VIS loops are used (e.g. you can end up with 0xFE for a component value instead of 0xFF). It's not clear whether the VIS loops are doing anything wrong; we've suspected that the rounding issue is inherent to the use of VIS instructions. I suppose we could open a separate bug to document that issue if necessary. But for now the specific bug reported here (reg test failing) has been fixed, so I will close this as a duplicate of 6258131.
19-10-2005
EVALUATION The test has a number of bad programming practices in it. First, there is no protection against the type of image created from the default GraphicsConfig. The test could be running on a grayscale visual for all that it knows. To be more robust, it should attempt to figure out how "red" will be drawn on the destination rather than assuming that it will be drawn perfectly. Alternatively it could test for "not black" instead of "exactly red", or it could fetch the color and test if it is closer to black or red. All that being said, it is a little disturbing that it didn't end up with pure red as most default visuals on Solaris machines should have that color available. Also, rather than a sleep loop, waits and notifications should be used to poll for trigger conditions: done = false; synchronized void waitForDone() { while (!done) { try { wait(2000); } catch (Exception e) { return /* false? */; } } } synchronized void finished() { done = true; notifyAll(); } Also, when I am trying to make sure that rendering occurs, usually I pick a more central location on the image rather than a border location. All that being said, I'd like to track down why we aren't getting perfect red before I consider whether these issues in the test case are the cause of the problem or merely nits... ###@###.### 2003-10-09
09-10-2003