Hi Clemens,
The definition of COMP_ISCOPY is that a value simply needs to be stored
in the destination without any blending to perform the rendering. CLEAR
essentially behaves like SRC, but with a hardcoded color of all 0s (i.e.
as long as you ignore the current color), and SRC_IN to an opaque
destination is classified as ISCOPY because it also behaves like SRC.
You should be able to use the same code as SRC for CLEAR, but you are
rejecting that operation. And, if the destination is opaque then SRC_IN
is identical to SRC, but you are rejecting that as well.
Perhaps the lower layers are ignoring ISCOPY and seeing the SRC_IN or
CLEAR and using different code, but they should vector to the SRC code
in those cases rather than rejecting them at the validate stage...?
...jim
On 10/3/13 8:12 AM, Clemens Eisserer wrote:
Hi,
Please review my fix-suggestion for the problem described below
available at: http://cr.openjdk.java.net/~ceisserer/fix11/webrev.03/
A testcase is available at:
http://cr.openjdk.java.net/~ceisserer/fix11/TextCompTest.java
Problem description:
When rendering Text with AlphaComposite.SrcIn and Src/SrcIn with EA,
the accelerated D3D/OGL pipelines render black boxes arround
individual glyphs.
As far as I can see, this is caused by an invalid check during
pipeline validation:
/* CompositeType.SrcNoEa (any color) */
- (sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY &&
- sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR)
From my understanding the check should allow for using the accelerated
text pipeline for AlphaComposite.SRC when a color is used as source.
However, as is the check also accepts the composition rules CLEAR,
SRC, SRCIN regardless of extra alpha.
Fix description:
The fix makes the check strikter to explicitly check for
comp-rule==Src and the currently set extra-alpha == 1.
It only fixes the issue for the OpenGL pipeline, but the changes
should apply 1:1 for the D3D pipeline.
Thanks, Clemens
