This fixes it, although the same may need to be done to OGL and D3D
subclasses
of SurfaceData.java
-phil.
diff --git a/src/share/classes/sun/java2d/SurfaceData.java
b/src/share/classes/sun/java2d/SurfaceData.java
--- a/src/share/classes/sun/java2d/SurfaceData.java
+++ b/src/share/classes/sun/java2d/SurfaceData.java
@@ -450,6 +450,7 @@ public abstract class SurfaceData
// For now the answer can only be true in the following cases:
if (sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY &&
sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR &&
+ sg2d.imageComp != CompositeType.Src &&
sg2d.clipState <= SunGraphics2D.CLIP_RECTANGULAR &&
sg2d.surfaceData.getTransparency() == Transparency.OPAQUE)
{
Phil Race wrote:
I didn't get time to look at this yesterday.
I think the problem is (sort of) in SunGraphics2D.setComposite() where
we have
}
} else if (newCompType == CompositeType.SrcNoEa ||
newCompType == CompositeType.Src ||
newCompType == CompositeType.Clear)
{
This then categorises the composite state "SRC" as COMP_ISCOPY
regardless of whether there is an extra alpha.
This code was introduced in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957
I believe that there's some handling of the extra alpha for most
rendering but
its enough to mislead SurfaceData into thinking it can create and use
LCD glyphs.
I've not yet looked into what exactly happens after that but it
seems like we end up in a loop that uses the LCD glyph
data as if its greyscale mask and you'll get garbage.
If this is the case we can't rely on the compositeState variable and
will need to check the composite type.
-phil.
Denis Lila wrote:
Hello.
After noticing some weird things I made some modifications to
Clemens' test. I've attached the results and the tester.
The most interesting results are the first 18 lines in each
image, all of which are produced by rendering to INT_RBG type
buffered images. The first 6 lines have both AA_ON and subpixel aa.
Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON.
In each group of 6, the only thing that changes is the order in
which the hints, the composite, and the colour are set.
Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06).
The only thing they have in common is that the AA hint is on.
Lines 7-12 look ok - they only have LCD AA. We can see that the order
doesn't matter.
On openJDK7 (with a build of a fresh clone of the 2d tree) lines
1-3 look like what Clemens is seeing, but the next 3 don't look bad,
even though all of the first 6 lines are supposed to be drawn with
a black colour, SRC compositing, and both AA_ON and LCD AA.
The same goes for lines 13-15. What lines 1-3 and 13-15 have in
common is that the colour is set after the composite.
Lines 7-12 still look ok, but they are a bit different from what closed
java produces, even though subpixel antialiasing is clearly used in
both.
That's it for my observations.
Regards,
Denis.
----- "Clemens Eisserer" <linuxhi...@gmail.com> wrote:
Hi again,
Attached is the sample program as well as the output I get on
jdk7b99,
when running the sample program attached.
- Clemens
------------------------------------------------------------------------
------------------------------------------------------------------------
