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.
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
Comments
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