Bug ID: JDK-5106309 OGL: xor mode broken

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 6

Priority: P4
Status: Resolved
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2004-09-23
Updated: 2005-04-18
Resolved: 2005-04-18

JDK 6
6 b33Fixed

XOR mode with the OpenGL-based pipeline enabled has been broken since the
fix for 4973983.  This can be reproduced using the following regression test:
test/sun/java2d/SunGraphics2D/PolyVertTest.java

EVALUATION This was a silly mistake introduced by the "Java level context validation" changes under 4972983. The problem is that in OGLContext_setXorComposite(), we pass in the xorPixel value, but we never set that value into oglc->xorPixel, as is necessary for the value to be used properly by the OGLContext_setColor() method. Since we were not setting oglc->xorPixel, that value was always zero when it was used in the setColor() method, and therefore the color used in XOR mode was always incorrect. ###@###.### 2004-09-23 While fixing this bug, I encountered another issue that needs to be addressed. In OGLSurfaceData.validatePipe(), we will install the Gradient or Texture renderer even if XOR mode is enabled. This is a problem because the accelerated Gradient and Texture renderers are not prepared to work in XOR mode. (We could probably make at least the Gradient case in XOR mode, but it's such an uncommon case that it's not worth cluttering the code.) Therefore, we should fix validatePipe() so that it only installs the Gradient and Texture renderers in COMP_ISCOPY or COMP_ALPHA modes. In theory, we should then handle the COMP_XOR case using our software loops. Unfortunately though, in XOR mode when there is a complex Paint we use our GeneralXorBlit, which tries to call OGLSurfaceData.getRaster(), which is unimplemented. There is an existing bug (4390163) about custom compositing not working for onscreen surfaces, so someday we need to address that. But for now, that is out of the scope of this bug, so I propose to make the suggested fix to validatePipe(), but comment-out the part of the regression test that tests this behavior. Once we address 4390163, then complex Paints should work with the OGL pipeline in XOR mode, and we can uncomment that part of the regression test. ###@###.### 2005-1-20 00:39:14 GMT As part of this fix, we should also try to make text work reasonably well in XOR mode. We can make our existing drawGlyphList() implementation render XOR text by enabling the alpha test so that it rejects transparent fragments (the non-zero areas in the glyph image will pass through). The OGL color state is XOR mode is setup to be (xorPixel ^ fgPixel), so the OGLTextRenderer will effectively modulate that value with the non-zero pixels in the glyph image, and then the OGL logic op will take care of XOR'ing that result with the destination. This approach works well for both non-AA and AA text. (AA text doesn't entirely make sense in XOR mode, but at least the OGL pipeline now produces reasonable results in this case, instead of throwing an exception, as it did before this fix.) In both cases, the operation is reversable, which is one of the defining properties of XOR mode. ###@###.### 2005-03-03 01:41:31 GMT

03-03-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang

24-09-2004

SUGGESTED FIX *** /tmp/geta25237 Thu Sep 23 11:53:17 2004 --- OGLContext.c Thu Sep 23 11:52:43 2004 *************** *** 414,419 **** --- 414,420 ---- // update state oglc->compState = sun_java2d_SunGraphics2D_COMP_XOR; + oglc->xorPixel = xorPixel; oglc->extraAlpha = 1.0f; } ###@###.### 2004-09-23

23-09-2004

Relates :	JDK-6240556 - avoid antialiasing text when XOR mode is enabled
Relates :	JDK-4390163 - Custom Composite implementations don't work on the screen