JDK-6588884 : PIT:D3D: Few regression test fails on WinXP with Nvidia FX boards.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u5
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-08-03
  • Updated: 2010-10-14
  • Resolved: 2007-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b03Fixed
Related Reports
Relates :  
JDK-6593406 - the BlitBg generic loop doesn't do bounds clipping properly
Relates :  
JDK-6588917 - PIT: D3D: PixelInterpolationTest from J2DGraphics fails on WinXP - Nvidia
Relates :  
JDK-6587863 - PIT: D3D: Pixelization issues with all Swing Components
Description
Description:
============
The following regression tests fails on WinXP(sp2).It's having a Nvidia Geforce FX5900XT with latest driver (162.18) from nvidia.But all these tests are passing with 6u3 b02 for same configuration(Nvidia Geforce FX5900XT with latest driver (162.18)).

sun/java2d/SunGraphics2D/PolyVertTest.java
sun/java2d/volatileImage/VolatileRestoration.java
sun/java2d/GdiRendering/InsetClipping.java
java/awt/font/TextLayout/TestHitToPoint.java
java/awt/font/Rotate/RotateTest3.java
java/awt/BasicStroke/DashZeroWidth.java
sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java
sun/java2d/SunGraphics2D/SimplePrimQuality.java
sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java
sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh

All the above tests are also reproducible except two tests(InsetClipping,RotateTest3) on ATI Radeon 9600 / X1050 Series with WinXP(sp2).
 
InsetClipping and RotateTest3 are passing on ATI Radeon 9600 / X1050 Series with WinXP(sp2).

JDK Info:
=========
java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b01)
Java HotSpot(TM) Client VM (build 1.6.0_03-ea-b02, mixed mode, sharing)
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u4/6588884.1
17-08-2007
EVALUATION sun/java2d/SunGraphics2D/SimplePrimQuality.java The problem with this failure is that since the d3d pipeline doesn't accelerate xor mode we use get/setPixel via the DataBufferNative. But since D3DNativeDataBuffer.setElem() call D3DContext.validate() (it doesn't need to - the set pixel op doesn't change the state) it doesn't mark the surface dirty, which is important if the surface is managed by the screen update manager. Since the manager doesn't see that there was some rendering done to the surface it doesn't flip it, and the Robot's grab gets incorrect image. The fix is to call sData.markDirty from D3DDataBufferNative.setElem(). This is the last failed test in this batch.
16-08-2007
EVALUATION sun/java2d/SunGraphics2D/PolyVertTest.java there are two issues with this test: 1. the exception mentioned in the report: Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.java2d.loops.GeneralRenderer.doDrawPoly(GeneralRenderer.java:144) at sun.java2d.loops.XorDrawPolygonsANY.DrawPolygons(GeneralRenderer.java:903) at sun.java2d.pipe.LoopPipe.drawPolyline(LoopPipe.java:83) at sun.java2d.pipe.ValidatePipe.drawPolyline(ValidatePipe.java:114) at sun.java2d.SunGraphics2D.drawPolyline(SunGraphics2D.java:2214) This is a bug in GeneralRenderer (which the pipeline uses for xor rendering). doDrawPoly doesn't check that the number of points is 0 and tries to access the array. Once this is fixed, however, we run into the second issue: the test fails because of known rendering artifacts (for onscreen and VI destination). This second issue will dealt separately in the fix for 6587863.
16-08-2007
EVALUATION Save goes for TestHitToPoint/RotateTest3 - while they're not full-screen, the cause of the exception is the same.
16-08-2007
EVALUATION sun/java2d/volatileImage/VolatileRestoration.java This one is full-screen related, will deal with it later as part of full-screen fixes (like this one - 6587853)
16-08-2007
EVALUATION sun/java2d/GdiRendering/InsetClipping.java The problem with this one was that the Robot was grabbing the pixels off the screen before the Screen updater flipped the onscreen surfaces. Adding Toolkit.sync() before Robot.createScreenCapture() didn't help however because D3D sync only woke up the screen update thread (by calling D3DScreenUpdateManager.wakeUpUpdateThread()), without waiting for the completion of the updates. This will need to be fixed - for VI->screen copies and Toolkit.sync we must flush the onscreen surfaces immediately, so a new method was added: D3DScreenUpdateManager.runUpdateNow() which does the update synchronously. Another good thing would be to add Toolkit.sync() to Robot.createScreenCapture().
16-08-2007
EVALUATION I've filed a separate bug about the BlitBg issue: 6593406: the BlitBg generic loop doesn't do bounds clipping properly since it's not specific to the d3d pipeline and this release. Note that the same issue happens with Argb src image type.
15-08-2007
EVALUATION sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java This one has two issues. First, just like other tests, it doesn't hanlde VolatileImages correctly - doesn't validate and check for lost state. After this is fixed, the test passes. However, if the window's size is increased to trigger the use of onscreen d3d rendering, the test fails: Testing source: BufferedImage@4cee32: type = 0 DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=1000000 IntegerInterleavedRaster: width = 50 height = 50 #Bands = 4 xOff = 0 yOff = 0 dataOffset[0] 0 testing blit rect src: java.awt.Rectangle[x=0,y=0,width=30,height=30] dst: java.awt.Rectangle[x=-10,y=-10,width=30,height=30] calculated dest rect:java.awt.Rectangle[x=0,y=0,width=20,height=20] subtest passed testing blit rect src: java.awt.Rectangle[x=-10,y=-10,width=50,height=50] dst: java.awt.Rectangle[x=0,y=0,width=50,height=50] calculated dest rect:java.awt.Rectangle[x=10,y=10,width=40,height=40] Test failed at x=0 y=0 expected: ff00ff00 got:ffff0000 Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Test failed at x=0 y=0 This test is copying a 1-bit transparent image using drawImage with specified bg color, with the following src and dest coords: src: java.awt.Rectangle[x=-10,y=-10,width=50,height=50] dst: java.awt.Rectangle[x=0,y=0,width=50,height=50] The result is supposed to be a red rectangle at java.awt.Rectangle[x=10,y=10,width=40,height=40] but instead we get java.awt.Rectangle[x=0,y=0,width=50,height=50] Note that the OpenGL pipeline produces the same failure. If the 1-bit transparent source image is excluded from the test, it passes for both opengl and d3d pipelines. The problem is that since there's no accelerated BlitBg loop, a generic loop is used (sun.java2d.BlitBg.General). From the BlitBg.General.BlitBg() method: fillop.FillRect(sg2d, tmpData, 0, 0, width, height); combineop.Blit(srcData, tmpData, AlphaComposite.SrcOver, null, srcx, srcy, 0, 0, width, height); blitop.Blit(tmpData, dstData, comp, clip, 0, 0, dstx, dsty, width, height); This loop first creates an intermediate image 50x50, fills it with the background color and then makes a blit from the source image (x,y,w,h) (-10,-10,50,50) - to the temp image (0, 0, 50, 50), and then blits this temp image (0, 0, 50, 50) to the destination (0, 0, 50, 50) - which produces the incorrect result. What needs to happen instead is this: the loop needs to to calculate the correct bounds for the first blit from srcData to tmpData (0, 0, 40, 40) -> (10, 10, 40, 40) and adjust the bounds of the final blit from tmpData to dstData: (10, 10, 40, 40) -> (10, 10, 40, 40) The problem is that there is no information about the dimensions of the src/dst surfaces at BlitBg level, so I'm not sure exactly what's the best way to fix this. May be the clipping should have happened earlier. At this point I'll just fix the test to handle the VI correctly and exclude 1-bit transparent image type from testing.
15-08-2007
EVALUATION sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java The problem with this one is a bug in optimization logic in BufferedContext.validate(): if the sequence of operations is like this: tx operation (transform blit) non-tx op (fillRect) tx operation (transform blit) - with the same transform as the first one then we do not set the transform the for the second tx op. When the trasnform is reset for the fillRect we do not reset the saved validated tx values, so next time a transform comes we think that the transform is already set. One way to fix it is like this: *** BufferedContext.java: 1.6 --- BufferedContext.java *************** *** 182,188 **** double nTransX = xform.getTranslateX(); double nTransY = xform.getTranslateY(); ! if (nTransX != vTransX || nTransY != vTransY || nScaleX != vScaleX || nScaleY != vScaleY || nShearX != vShearX || nShearY != vShearY) { --- 182,189 ---- double nTransX = xform.getTranslateX(); double nTransY = xform.getTranslateY(); ! if (!xformInUse || ! nTransX != vTransX || nTransY != vTransY || nScaleX != vScaleX || nScaleY != vScaleY || nShearX != vShearX || nShearY != vShearY) { I now wonder if this whole optimization worth it.
15-08-2007
EVALUATION sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh This one is due to a bug in the test. It doesn't validate the VolatileImage when copying it to the screen (only validates it once when creating). In the current pipeline if a VI is copied to the screen (for cases where we do not enable onscreen d3d rendering - like in this case, since the window is too small) we disable the acceleration in such VI and set the lost state. Which means that the first attempt to copy it to the screen wiill not produce any results. After fixing the test to validate the image and respond correctly to the return codes the test passes. One done, tons to go =)
15-08-2007