[OpenJDK 2D-Dev] Fix suggestion: Black boxes arround glyphs with SrcIn and Src/SrcIn+EA [OGL, D3D]

[Jim Graham]

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
>