JDK-6244071 : PIT: OGL: Swing is broken on OpenGL pipeline with the gray rect fix, Win32
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-03-22
  • Updated: 2008-02-06
  • Resolved: 2005-04-13
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
6 b32Fixed
Related Reports
Relates :  
JDK-6245358 - PIT: OGL:ClassCastException thrown with OGL while disabling the HW acceleration at runtime, WinXP
Description
I am running SwingSet2 on the Swing PIT build dated 19.Mar.2005 with OpenGL pipeline on WinXP and I am seeing lot of rendering artifacts. The application is totally distorted and not usable. 

Here is the PIT build(Respin):
java version "swing-jcg-win-03-2005-03-21-int.mustang"
Java(TM) 2 Runtime Environment, Standard Edition (build swing-jcg-win-03-2005-0-21-int.mustang)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b28, mixed mode)

I tried this on NVidia GeForce4 MX440 as well as MX4000 and reproducible on both on WinXP. I tried this on Linux with ATI Radeon9600XT and seeing similar artifacts but those were seen even on promoted builds also. So this looks like a PIT failure only on WinXP. Use the flag '-Dsun.java2d.opengl=True' when running SwingSet2 and make sure you get a message on the console that OpenGL is enabled on the system.

Not reproducible on  b26, 27 on the same WinXP system and hence this is a PIT failure on the Swing PIT build.
###@###.### 2005-03-22 07:34:54 GMT
Comments
EVALUATION The problem is in OGLBlitTextureToSurface(). If the source is a render-to-texture surface and only a subregion of the source surface is being copied, we calculate the y1/y2 texture coordinates incorrectly. This bug has been present since the OGL pipeline was extended to the Windows platform in 5.0, but it was just uncovered in the Swing workspace because the gray rect fix (buffer per window) uses subregion copies from a VolatileImage backbuffer to the screen. First, a note about render-to-texture (RTT) surfaces. The contents of an RTT surface are stored as if in a pbuffer, but to copy the contents out of that surface, you must texture map that surface to a quad. Due to the way we flip the OGL viewport, the bottom scanline of the image contents (from the perspective of Java 2D) of an RTT surface is actually colocated with the top edge of the texture object that corresponds to the RTT surface. Likewise, the top scanline of the image contexts falls somewhere near the bottom of the texture object. (Only images with pow2 dimensions will have their top scanline coexistent with the bottom edge of the texture object.) To illustrate this, imagine a 400x400 VolatileImage. We will create a 512x512 pbuffer/texture object for this image (since RTT surfaces must be have pow2 dimensions in OpenGL). The bottom-left coordinate of the VI (from Java 2D's perspective) should be referenced with a texture coordinate of (0.0, 0.0). (Remember, texture coordinates are specified relative to the top-left corner of the texture object, just to make things really confusing here.) The top-left coordinate of the VI should be referenced with (0.0, (400/512)). The top-right coordinate would be ((400/512), (400/512), and the bottom-right would be ((400/512), 0.0). Before, the non-subregion case worked fine only because Swing would always call drawImage() so that the source parameters would be (0, 0, imgw, imgh). In that case, we would simply swap the sy1 and sy2 coordinates so that the texture mapping would work correctly. This works when sy1=0 and sy2=imgHeight, but breaks down for all other cases. We should really be specifying the texture coordinates relative to the top edge of the VolatileImage (from Java 2D's perspective), as described earlier. So instead of just swapping the sy1/sy2 coordinates, we should have the following code: if (rtt) { sy1 = srcOps->height - sy1; sy2 = srcOps->height - sy2; } So using the earlier example, this code should work well for the case when sy1=0 and sy2=imgWidth (we'll still get the same swapping behavior), but the subregion case will work as well now. With this fix in place, Swing is working properly out-of-the-box on Windows when the OGL pipeline is enabled. ###@###.### 2005-03-22 09:16:34 GMT
22-03-2005