JDK-6597822 : D3D: improve pipeline's rendering quality for some cases
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u5
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-08-27
  • Updated: 2010-10-14
  • Resolved: 2007-09-18
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 b04Fixed
Related Reports
Relates :  
JDK-6587863 - PIT: D3D: Pixelization issues with all Swing Components
Description
While the fix for 
  6587863: PIT: D3D: Pixelization issues with all Swing Components
fixed all known problems with rendering of Swing components
on all hw there are still some cases where the quality could be 
improved.

Here are a few known cases:
  - PolyVertTest reg. test (with -fulltest) still fails with about 10 pixels - 
    due to the fact that we do not tweak the geometry in drawPoly
  - we only tweak the geometry for proper texel to pixel 
    alignment for DrawTexture and FillRect,
    which leaves otehr primitives prone to minor texture mapping
    pixelization errors. This is especially important for the drawScanlines()
    case which is used for filling shapes with Paint
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u5/6597822.0
06-09-2007
EVALUATION Regarding the failures in 'PolyVertTest -fulltest -hwonly' . The part of the test that fails is where we render polyline/polygon with Xor mode (the last for loop in render()). Since xor is not hw accelerated in the d3d pipeline we use the GeneralRenderer (via XorDraw*Any::Draw*), and all the hw pipeline does is get/set pixel at given coordinates passed by the renderer. I've reproduced the same rendering artifacts when rendering to a custom buffered image. So this appears to be a bug in the GeneralRenderer renderer. I will file a separate bug to track this issue.
28-08-2007
EVALUATION For the first issue: Fixing drawPoly will be tricky - we'll need to apply geometry tweaking for each pixel in the polyline. For the second: We'd need to find special fudge factors for tweaking the geometry such that it doesn't change the shape, but still allows for proper texel to pixel alignment.
27-08-2007