JDK-6603000 : D3D: incorrect texel to pixel mapping in 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-09-10
  • Updated: 2011-03-30
  • Resolved: 2007-09-24
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-6602861 - D3D: Nimbus L&F: Painting broken on some D3D cards
Description
the pipeline still doesn't map texels pixels to pixels correclty
in case of complex transforms.

This is visible with Nimbus L&F on some video boards (see
the attached screenshot).
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u5/6603000.0
19-09-2007
EVALUATION In the end we decided on fixing tex-pix mapping by shifting the geometry by -0.5 post-transform. And luckily we already had a fix for the texture bleeding with bilinear filtering ready for the opengl pipeline, so we used it.
18-09-2007
EVALUATION The fix for 6602861 addressed most of the rendering issues with Nimbus L&F, but unfortunately not all. For example, when painting vertical scrollbars Nimbus scales and rotates a translucent volatile image to render the track of the scroll bar. On some video boards this results in a 1-pixel high hole at the bottom of the track (above the sc button). This is because the way we use texture transform to offset the texture for proper texel to pixel mapping is still not entirely correct - it only looks at the device's scale factors. Also, when rendering a background of a menu bar, one can see some texture bleeding on the right side, most likely because the board doesn't support non-pow2 textures and so the bilinear filtering is sampling texels from outside of the "image"'s bounds in a texture.
10-09-2007