From ahughes at redhat.com  Mon Jun  7 18:05:18 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Mon, 7 Jun 2010 19:05:18 +0100
Subject: [OpenJDK 2D-Dev] Use of obsolete png_check_sig function in
	splashscreen_png.c
In-Reply-To: <20100524180707.GA32211@rivendell.middle-earth.co.uk>
References: <AANLkTin5SVJZG339LmslmUsnVcPqjHypF30ugWncOzcZ@mail.gmail.com>
	<4BF5665A.9000702@oracle.com>
	<20100524180707.GA32211@rivendell.middle-earth.co.uk>
Message-ID: <AANLkTikhqoSrIOu_q_Gm8qwE6MqJjTFgFCKssk1SESp0@mail.gmail.com>

On 24 May 2010 19:07, Andrew John Hughes <ahughes at redhat.com> wrote:
> On 09:42 Thu 20 May ? ? , Phil Race wrote:
>> ?From http://www.libpng.org/pub/png/libpng.html
>>
>> ?>The current public release, *libpng 1.4.2*, restores the 1.2.x
>> png_check_sig() macro ...
>>
>> I suppose removing it caused too many problems.
>>
>
> Ah, that explains why I couldn't replicate the failure recently and
> it was still in the local header file I checked.
> It's not exactly prominent on that page and the differences document
> still lists it as obsolete.
>
> I'd be interested to know why they reverted the decision.
>
>> So whilst I see nothing wrong with this change, I wonder if its worth
>> the trouble ?
>
> Well, it's no great trouble for me to push it given I've already made
> the (very minor) change. ?And if it isn't changed in OpenJDK upstream,
> I imagine the change will still have to stay around for a while in
> IcedTea to cover the 1.4.0 and 1.4.1 releases that do remove the
> macro (given we build against the system library, rather than the
> in-tree one).
>
>>
>> If you still want to push I'll supply a bug id.
>>
>
> Thanks, that'd be good.
>
>> 2 other things
>> 1) Not that it ?matters (just FYI) but splashscreen is considered to be
>> AWT not 2D,
>> even though libpng itself is 2D. Relevant only because the bug would be
>> classes_awt,
>> not classes_2d.
>
> I always seem to get this wrong; the last two patches I sent to the
> awt list and was told to send here. ?Is there a guide to who has
> responsibility for what? ?It's certainly not clear from the
> openjdk.java.net pages, which indeed still list OpenJDK as having
> encumberances in the area of 2D; that hasn't been the case for a
> couple of years.
>
>> 2) Maybe we are due to upgrade the libpng in JDK ? We upgraded it
>> last in May ?2007 right before launching openjdk, then to 1.2.18
>> Was there ever a 1.3.X ?? Looks like that got skipped for some reason.
>> Doesn't seem urgent but it might be a good thing to add to the to-do list.
>>
>
> I've never seen a 1.3. ?Maybe they use the odd numbers as a development branch
> as is the case with Gtk+ and used to be the case with Linux prior to 2.6.
>
> In 1.4, the main changes are apparently 'support for the iTXt chunk
> and a function for limiting the amount of memory that a possibly
> malicious compressed chunk can consume.' ?The former is only really
> needed if files with iTXt chunks become prominent in the wild (which
> seems unlikely until 1.4 is widespread). ?The other change sounds like
> it could be more important.
>
> >From our side, I think it would be more useful to see in-tree support
> for building against the system libpng as we never use the in-tree
> version anyway. ?Using the system version means we are better covered
> for security updates and new versions of libpng don't first need to be
> imported into the OpenJDK tree.
>
>> -phil.
>>
>> Andrew John Hughes wrote:
>> > With libpng 1.4, the png_check_sig function has been removed, having
>> > been deprecated in previous releases:
>> >
>> > http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt
>> >
>> > This function is used in splashscreen_png.c and can be easily be
>> > replaced with png_sig_cmp, as in this webrev:
>> >
>> > http://cr.openjdk.java.net/~andrew/libpng/webrev.01/
>> >
>> > This actually makes the line clearer as the not operator is no longer needed.
>> > I know OpenJDK still uses an in-tree libpng 1.2 by default, but this
>> > fix still works with that version and also means that the code will
>> > still build, should the internal libpng be upgraded to 1.4.
>> >
>> > Ok to push this? ?If so, can I have a bug ID for it?
>> >
>> > Thanks,
>> >
>>
>
> --
> Andrew :)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint = F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>

So can I have a bug ID for this?

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From philip.race at oracle.com  Mon Jun  7 18:50:40 2010
From: philip.race at oracle.com (Phil Race)
Date: Mon, 07 Jun 2010 11:50:40 -0700
Subject: [OpenJDK 2D-Dev] Use of obsolete png_check_sig function in
	splashscreen_png.c
In-Reply-To: <AANLkTikhqoSrIOu_q_Gm8qwE6MqJjTFgFCKssk1SESp0@mail.gmail.com>
References: <AANLkTin5SVJZG339LmslmUsnVcPqjHypF30ugWncOzcZ@mail.gmail.com>	<4BF5665A.9000702@oracle.com>	<20100524180707.GA32211@rivendell.middle-earth.co.uk>
	<AANLkTikhqoSrIOu_q_Gm8qwE6MqJjTFgFCKssk1SESp0@mail.gmail.com>
Message-ID: <4C0D3F80.7030000@oracle.com>

On 6/7/2010 11:05 AM, Andrew John Hughes wrote:


>
> So can I have a bug ID for this?
>
> Thanks,
>    

oops .. guess I missed your last reply.

6959123: Remove use of obsolete png_check_sig function in splashscreen_png.c

-phil.



From Anthony.Petrov at Sun.COM  Tue Jun  8 12:57:09 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Tue, 08 Jun 2010 16:57:09 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> Use of obsolete
 png_check_sig	function in splashscreen_png.c
In-Reply-To: <AANLkTikhqoSrIOu_q_Gm8qwE6MqJjTFgFCKssk1SESp0@mail.gmail.com>
References: <AANLkTin5SVJZG339LmslmUsnVcPqjHypF30ugWncOzcZ@mail.gmail.com>
	<4BF5665A.9000702@oracle.com>
	<20100524180707.GA32211@rivendell.middle-earth.co.uk>
	<AANLkTikhqoSrIOu_q_Gm8qwE6MqJjTFgFCKssk1SESp0@mail.gmail.com>
Message-ID: <4C0E3E25.5040302@sun.com>

Hi Andrew,

On 06/07/2010 10:05 PM, Andrew John Hughes wrote:
>> >From our side, I think it would be more useful to see in-tree support
>> for building against the system libpng as we never use the in-tree
>> version anyway.  Using the system version means we are better covered
>> for security updates and new versions of libpng don't first need to be
>> imported into the OpenJDK tree.

There's a CR 6565114 (Allow using system copies of libjpeg, libpng and 
giflib for splashscreen) for this task. However we've never seen a 
working version of the patch.

--
best regards,
Anthony


From mario.torre at aicas.com  Tue Jun  8 13:37:39 2010
From: mario.torre at aicas.com (Mario Torre)
Date: Tue, 08 Jun 2010 15:37:39 +0200
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <1275071159.2300.10.camel@galactica>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica>
	<4BF325E8.6080301@oracle.com> <1274257734.1895.8.camel@moonlight>
	<4BF4594B.8070400@oracle.com>  <1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight>
	<1275071159.2300.10.camel@galactica>
Message-ID: <1276004259.4815.6.camel@galactica>

Il giorno ven, 28/05/2010 alle 20.25 +0200, Mario Torre ha scritto:

> Ok, I tried to send once, but the message is moderated as it's too big.
> 
> I've uploaded the package here:
> 
> http://www.limasoftware.net/neugens/downloads/stuff/font2dbug/FontTest.tar.gz

Hi all,

Is there still any interest in this?

Cheers,
Mario
-- 
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas GmbH, Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards: http://endsoftpatents.org/



From jon.vanalten at redhat.com  Tue Jun  8 14:10:21 2010
From: jon.vanalten at redhat.com (jon.vanalten at redhat.com)
Date: Tue, 8 Jun 2010 10:10:21 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length
In-Reply-To: <2059186105.201421276005357393.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <1912367199.205001276006221680.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>

<BUMP>

Hi, I sent this a while ago.  Wondering if anyone has any feedback?

thanks in advance,

jon



----- "jon vanalten" <jon.vanalten at redhat.com> wrote:

> Hi,
> 
> I am new to this list, hopefully it is okay that I post a potential
> fix to a very minor rendering bug.
> 
> I've been looking at a bug reported downstream at IcedTea:
> 
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=383
> 
> To summarize, if a line is drawn via Graphics2D.drawLine() of zero
> length but thickness greater than 1, the endcap decorations are not
> rendered.  This is because the sun.java2d.pisces.Stroker class ignores
> such line segments.  This is ideal in most situations drawing complex
> shapes, but when such a line segment is the entire shape the end
> result nothing at all is rendered.  The closed-source Sun JDK
> implementation does render endcap decorations in this case, and the
> documentation of the BasicStroke class related to this suggests that
> they should be rendered.
> 
> I've put together a (possibly straw-man) fix.  Please do pick it
> apart, I have never looked at the graphics implementation before
> trying to tackle this bug.  I basically add a boolean to indicate that
> the finish() step should be taken if *any* lineTo() call has occurred,
> and in the finish() step detect if there are any segments and if no
> manually draw in the caps (while allowing normal behaviour in other
> cases).
> 
> See webrev at:
> 
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev/
> (or download)
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev.zip
> 
> Your comments are appreciated.
> 
> cheers,
> 
> jon


From ahughes at redhat.com  Tue Jun  8 16:52:59 2010
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Tue, 08 Jun 2010 16:52:59 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6959123: Remove use of obsolete
	png_check_sig	function in splashscreen_png.c
Message-ID: <20100608165310.800D54705F@hg.openjdk.java.net>

Changeset: 4d55419ce99e
Author:    andrew
Date:      2010-06-08 17:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4d55419ce99e

6959123: Remove use of obsolete png_check_sig function in splashscreen_png.c
Summary: Avoid use of deprecated libpng macro (removed in some 1.4.x releases)
Reviewed-by: prr

! src/share/native/sun/awt/splashscreen/splashscreen_png.c



From ahughes at redhat.com  Tue Jun  8 16:59:04 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Tue, 8 Jun 2010 17:59:04 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> Use of obsolete png_check_sig
	function in splashscreen_png.c
In-Reply-To: <4C0D3F80.7030000@oracle.com>
References: <AANLkTin5SVJZG339LmslmUsnVcPqjHypF30ugWncOzcZ@mail.gmail.com>
	<4BF5665A.9000702@oracle.com>
	<20100524180707.GA32211@rivendell.middle-earth.co.uk>
	<AANLkTikhqoSrIOu_q_Gm8qwE6MqJjTFgFCKssk1SESp0@mail.gmail.com>
	<4C0D3F80.7030000@oracle.com>
Message-ID: <AANLkTilbCPC9n95fODvyaElm2POewSQIPqJshfUrN9da@mail.gmail.com>

On 7 June 2010 19:50, Phil Race <philip.race at oracle.com> wrote:
> On 6/7/2010 11:05 AM, Andrew John Hughes wrote:
>
>
>>
>> So can I have a bug ID for this?
>>
>> Thanks,
>>
>
> oops .. guess I missed your last reply.
>
> 6959123: Remove use of obsolete png_check_sig function in splashscreen_png.c
>
> -phil.
>
>

Thanks, I've pushed this to the 2D tree.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From ahughes at redhat.com  Tue Jun  8 17:00:50 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Tue, 8 Jun 2010 18:00:50 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> Use of obsolete png_check_sig
	function in splashscreen_png.c
In-Reply-To: <4C0E3E25.5040302@sun.com>
References: <AANLkTin5SVJZG339LmslmUsnVcPqjHypF30ugWncOzcZ@mail.gmail.com>
	<4BF5665A.9000702@oracle.com>
	<20100524180707.GA32211@rivendell.middle-earth.co.uk>
	<AANLkTikhqoSrIOu_q_Gm8qwE6MqJjTFgFCKssk1SESp0@mail.gmail.com>
	<4C0E3E25.5040302@sun.com>
Message-ID: <AANLkTik1Rn08yEGPYowyY2rMO5KOdVN6ACKiHxfFl_NS@mail.gmail.com>

On 8 June 2010 13:57, Anthony Petrov <Anthony.Petrov at sun.com> wrote:
> Hi Andrew,
>
> On 06/07/2010 10:05 PM, Andrew John Hughes wrote:
>>>
>>> >From our side, I think it would be more useful to see in-tree support
>>> for building against the system libpng as we never use the in-tree
>>> version anyway. ?Using the system version means we are better covered
>>> for security updates and new versions of libpng don't first need to be
>>> imported into the OpenJDK tree.
>
> There's a CR 6565114 (Allow using system copies of libjpeg, libpng and
> giflib for splashscreen) for this task. However we've never seen a working
> version of the patch.
>

I wasn't aware of this bug ID so thanks for that.  I think the final
solution needs to cover more than just splashscreen though, as there
are other uses of libjpeg elsewhere.

I don't know about this patch by the bug reporter.  The one in IcedTea
is pretty unusable upstream; it removes the in-tree libraries and
forces system libraries.  That's fine for distros, but for OpenJDK we
don't want to disrupt the status quo.  I've been meaning to look at
this for a while, but just haven't got round to it.  Maybe after the
next IcedTea7 release...

> --
> best regards,
> Anthony
>

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From dlila at redhat.com  Wed Jun  9 20:13:29 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 9 Jun 2010 16:13:29 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <2115339356.638951276114402354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <373786287.638971276114409115.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello.

I think I have a fix for this bug:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506

Basically, the problem is that if there is a magnifying affine transformation set on the graphics object and one tries to draw a line with small thickness and round end caps, the end caps appear jagged. This is because the computation of the length of the array that contains the points on the "pen" with which the decoration is drawn does not take into account the size of the pen after the magnification of the affine transformation. So, for example, if the line length was set to 1, and the transformation was a scaling by 10, the resulting pen would have a diameter of 10, but only 3 pen points would be computed (pi*untransformedLineWidth), so the end cap looks like a triangle.

My fix computes an approximation of the circumference of the transformed pen (which is an ellipse) and uses that as the number of points on the pen. The approximation is crude, but it is simple, faster than alternatives (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can say from observations that it works fairly well.

There is also icing on the cake, in the form of slight improvements in performance when the scaling is a zooming out. Example: if the original line width was 100, but g2d.scale(0.1,0.1) was set, then the resulting line would have a width of 10, so only ~31 points are necessary for the decoration to look like a circle, but without this patch, about 314 points are computed (and a line is emitted to each one of them).

I appreciate any feedback.

Regards,
Denis Lila.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug506-fix.patch
Type: text/x-patch
Size: 2480 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100609/463dcd78/bug506-fix.patch>

From dlila at redhat.com  Wed Jun  9 22:49:35 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 9 Jun 2010 18:49:35 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for bug where long dashed lines can make
	graphics go black.
In-Reply-To: <1158471715.648971276123728748.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1645847476.649001276123775388.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello.

I think I have a fix for this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=597227

The bug was caused by a few integer overflows in sun/java2d/pisces/Dasher.java 
and sun/java2d/pisces/Stroker.java which would cause the whole container to
fill up with whatever colour the line had. Dasher.java was prone to 2 overflows:
one when computing the x and y coordinate lengths of the line at hand, and
another which actually happened in PiscesMath.hypot(int,int). I fixed these
two by turning the variables into longs and using PiscesMath.hypot(long,long).

Stroker.java was only prone to overflows when drawing end caps or when adding
offsets to points. I fixed these by making sure lineTo and moveTo never moved
too close to the boundaries set by Integer.MAX_VALUE and Integer.MIN_VALUE.

I welcome any feedback.

Thank you,
Denis Lila.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dashedLinesBlackWindowBugFix.patch
Type: text/x-patch
Size: 7068 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100609/45fa7955/dashedLinesBlackWindowBugFix.patch>

From james.graham at oracle.com  Wed Jun  9 23:42:33 2010
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 09 Jun 2010 16:42:33 -0700
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <373786287.638971276114409115.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <373786287.638971276114409115.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C1026E9.2070501@oracle.com>

I don't understand - why do we generate sample points based on the size 
of the cap?  Why not generate a pair of bezier quarter-circles and let 
the rasterizer deal with sampling?

			...jim

Denis Lila wrote:
> Hello.
> 
> I think I have a fix for this bug:
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
> 
> Basically, the problem is that if there is a magnifying affine transformation set on the graphics object and one tries to draw a line with small thickness and round end caps, the end caps appear jagged. This is because the computation of the length of the array that contains the points on the "pen" with which the decoration is drawn does not take into account the size of the pen after the magnification of the affine transformation. So, for example, if the line length was set to 1, and the transformation was a scaling by 10, the resulting pen would have a diameter of 10, but only 3 pen points would be computed (pi*untransformedLineWidth), so the end cap looks like a triangle.
> 
> My fix computes an approximation of the circumference of the transformed pen (which is an ellipse) and uses that as the number of points on the pen. The approximation is crude, but it is simple, faster than alternatives (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can say from observations that it works fairly well.
> 
> There is also icing on the cake, in the form of slight improvements in performance when the scaling is a zooming out. Example: if the original line width was 100, but g2d.scale(0.1,0.1) was set, then the resulting line would have a width of 10, so only ~31 points are necessary for the decoration to look like a circle, but without this patch, about 314 points are computed (and a line is emitted to each one of them).
> 
> I appreciate any feedback.
> 
> Regards,
> Denis Lila.
> 


From philip.race at oracle.com  Thu Jun 10 21:28:46 2010
From: philip.race at oracle.com (Phil Race)
Date: Thu, 10 Jun 2010 14:28:46 -0700
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <1275070336.2300.6.camel@galactica>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica> <4BF325E8.6080301@oracle.com>
	<1274257734.1895.8.camel@moonlight> <4BF4594B.8070400@oracle.com>
	<1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight>
	<1275070336.2300.6.camel@galactica>
Message-ID: <4C11590E.7040308@oracle.com>

I've root-caused this although its still not clear what's the ideal answer,
the simplest and safest may be Mario's proposed fix here from 5/5/2010 :

http://cr.openjdk.java.net/~neugens/100134/webrev.01/

So, yes, I think as Mario suggested it starts with something in
freetype which has a "#define GRID_FIT_METRICS" that causes [premature] 
rounding of metrics to integer values :-

#ifdef GRID_FIT_METRICS
 metrics->ascender    = FT_PIX_CEIL( FT_MulFix( face->ascender,
                                                metrics->y_scale ) );

 metrics->descender   = FT_PIX_FLOOR( FT_MulFix( face->descender,
                                                 metrics->y_scale ) );

 metrics->height      = FT_PIX_ROUND( FT_MulFix( face->height,
                                                 metrics->y_scale ) );

....

So 
height is ROUNDED
ascent is CEIL'd
descent is FLOOR'd.

Mario's fix essentially removes this integer rounding.

The FLOOR is because descent is negative and so the apparent intent is
to ensure that the int ascent and descent are at least as great in
magnitude as the float versions. But this is at the cost of
ascent+descent == height.

Freetype extracts ascent and descent from the 'hhea' table (same
as T2K as it happens), and the values there in upem are scaled
to the 12 pt example in Mario's test program. As shown here.
Arithmetic is actually fixed point but FP values are clearer.
You can then see the effect of the conversion to int's

FIELD      UPEM      | FP 12pt | Integer Val
ascent  | 1901       | 11.14      |   12 (CEIL'd)
descent | -483       | -2.83      |   -3 (FLOOR'd)
height  | 2384       | 13.97      |   14 (ROUNDed)


Note that ceil of ascent greatly increases it by almost a pixel
from its true value

If GRID_FIT_METRICS is not defined then no rounding
occurs and JDK code sees the floating point values
and it rounds in its own preferred way, and then
the results are the same as in the freetype and t2k cases.

But where does freetype get height, since the font provides
ascent, descent and linegap? The answer is its calculated
from those three :
  
    root->ascender  = face->horizontal.Ascender;
    root->descender = face->horizontal.Descender;

    root->height    = (FT_Short)( root->ascender - root->descender +
                                  face->horizontal.Line_Gap );

Line_Gap is not exposed freetype API, and so the leading value required
by Java API can only be derived by doing the reverse arithmetic.

However since freetype has already rounded for us, this information
is not reliable and we see the result as 14-(12+3) = -1 
JDK therefore cannot use freetype (via this exact API)
to faithfully report leading.

Regardless of how the rest of this works out, this part should be fixed.

Negative leading values are (surprisingly) legal but I think either
deprecated or extremely rare. So I think it reasonable that if we
see a negative leading we ignore it (ie clamp leading to zero).

Mario's proposed fix should have the same effect as it bypasses
the rounding and we will see the same raw values as in the T2K rasteriser

Whether its done like that or as part of something more complex
depends on the relationship of the asc+dsc+ldg to height.

Clamping to zero and summing gives us hgt= 12+3+0=15, whereas freetype reports
its actually 14 because the rounding happened to be almost completely
precise whereas the CEIL(ascent) added a whole pixel.

It could be even worse. Imagine if we had in floating point that descent=2.10
Then height would be rounded to 13, but ascent+descent would still be 15.

So should we ensure height = ascent + descent + leading ?
I consider this a grey area as it depends on how you interpret
ascent and descent and their relationship to height, but freetype clearly
derived height from these but doesn't see it as necessary for them to
add up.

JDK has in practice tried to maintain this equation but freetype clearly doesn't
regard it as invariant. In fact I updated the spec for FontMetrics.getHeight()
back in JDK 1.4 under bug 4455492 and tried to implement something like
this. This led directly to Swing problems listed in 4467709, so I
ended up having to go for the tamer solution today.
So if we allow for openjdk/freetype to return the height as 14, then
I'd still expect some Swing problems, although apparently some do exist
today. Basically, concurrent with the fix, someone would have to take
on everything Roman writes about here :

http://mail.openjdk.java.net/pipermail/swing-dev/2010-May/001034.html

and be on call to evaluate and fix up all the Swing bugs that are
reported. We'd also have to be ready in case anyone complained in
general about metrics changes breaking their UI layout. This has
caused HUGE customer complaints in the past. Technically it was
their own fault, but they still complained.

I also suspect AWT would have some issues, as all the metrics
come via the 2D path.

And to be able to do this, we'd really want to bypass all that
rounding done by freetype, else we'd have to propagate height
up separately. right now we only propagate up the raw ascent,
descent and leading, since we assume that they were left
as raw floating point values.

Mario's concern about hinting isn't founded. It doesn't matter.

So I think (bit of hand waving)
1) Implement Mario's fix which will solve negative leading
2) Separately consider the larger change to
   a) tighten up the height we reportywith the consequence that its common that
   getAscent()+getDescent()+getLeading() > getHeight()
   b) Fix up everywhere in the JDK that assumes otherwise ..
  (a) and (b) ought to be as much as possible in the same commit
   which means its a bigger job but still with follow-up inevitably needed.

  


-phil.


From igor.nekrestyanov at sun.com  Thu Jun 10 22:00:56 2010
From: igor.nekrestyanov at sun.com (igor.nekrestyanov at sun.com)
Date: Thu, 10 Jun 2010 22:00:56 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6952043: Incorrect JNI calls in
	fontpath.c
Message-ID: <20100610220108.7A6B6470F6@hg.openjdk.java.net>

Changeset: 2574d999704a
Author:    igor
Date:      2010-06-10 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2574d999704a

6952043: Incorrect JNI calls in fontpath.c
Reviewed-by: jgodinez, prr

! src/windows/native/sun/font/fontpath.c



From lana.steuck at oracle.com  Fri Jun 11 05:10:50 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Jun 2010 05:10:50 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: Added tag jdk7-b96 for changeset
	cf71cb515116
Message-ID: <20100611051050.ED52A47127@hg.openjdk.java.net>

Changeset: 5e197c942c6e
Author:    mikejwre
Date:      2010-06-03 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/5e197c942c6e

Added tag jdk7-b96 for changeset cf71cb515116

! .hgtags



From lana.steuck at oracle.com  Fri Jun 11 05:10:56 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Jun 2010 05:10:56 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 8 new changesets
Message-ID: <20100611051101.5BB1E47128@hg.openjdk.java.net>

Changeset: c16ac7e7a579
Author:    ohair
Date:      2010-05-26 20:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/c16ac7e7a579

6956202: Fix a few missed rebranding issues, please contact lines etc.
Reviewed-by: jjg, darcy, weijun

! src/share/classes/com/sun/corba/se/pept/package.html
! src/share/classes/com/sun/corba/se/spi/ior/package.html
! src/share/classes/com/sun/corba/se/spi/monitoring/package.html
! src/share/classes/javax/activity/package.html
! src/share/classes/javax/rmi/CORBA/package.html
! src/share/classes/javax/rmi/package.html
! src/share/classes/javax/transaction/package.html
! src/share/classes/javax/transaction/xa/package.html
! src/share/classes/org/omg/CORBA/DynAnyPackage/package.html
! src/share/classes/org/omg/CORBA/ORBPackage/package.html
! src/share/classes/org/omg/CORBA/portable/package.html
! src/share/classes/org/omg/IOP/CodecFactoryPackage/package.html
! src/share/classes/org/omg/IOP/CodecPackage/package.html
! src/share/classes/org/omg/IOP/package.html
! src/share/classes/org/omg/Messaging/package.html
! src/share/classes/org/omg/PortableInterceptor/ORBInitInfoPackage/package.html
! src/share/classes/org/omg/PortableInterceptor/package.html

Changeset: 1b5234624436
Author:    ohair
Date:      2010-05-28 10:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/1b5234624436

6956930: Remove unused OS_VENDOR make variable
Reviewed-by: trims

! make/common/shared/Platform.gmk

Changeset: edc2a2659c77
Author:    mikejwre
Date:      2010-06-02 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/edc2a2659c77

Merge


Changeset: 8c6e70ef006c
Author:    mikejwre
Date:      2010-06-03 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/8c6e70ef006c

Added tag jdk7-b96 for changeset edc2a2659c77

! .hgtags

Changeset: 888a846a860a
Author:    alanb
Date:      2010-06-01 15:16 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/888a846a860a

6955873: CORBA resources bundles and javax.activity missing from b94
Reviewed-by: ohair

- make/com/sun/corba/minclude/ioser_io.jmk
! make/sun/corba/Makefile
+ make/sun/corba/core/Makefile
! make/sun/rmi/rmic/FILES.gmk

Changeset: 1f87478a2d66
Author:    lana
Date:      2010-06-07 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/1f87478a2d66

Merge

- make/com/sun/corba/minclude/ioser_io.jmk

Changeset: 2657ee0d2d14
Author:    andrew
Date:      2010-06-03 19:37 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/2657ee0d2d14

6958257: Add support for alpha
Summary: Allow the Zero port to be built on alpha architectures
Reviewed-by: ohair

! make/common/Defs-linux.gmk

Changeset: 4ec9d59374ca
Author:    mikejwre
Date:      2010-06-09 18:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/4ec9d59374ca

Merge




From lana.steuck at oracle.com  Fri Jun 11 05:19:07 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Jun 2010 05:19:07 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: Added tag jdk7-b96 for changeset
	9510ed0e1c7a
Message-ID: <20100611051907.891174712A@hg.openjdk.java.net>

Changeset: ca01ec32561f
Author:    mikejwre
Date:      2010-06-03 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/ca01ec32561f

Added tag jdk7-b96 for changeset 9510ed0e1c7a

! .hgtags



From lana.steuck at oracle.com  Fri Jun 11 05:19:11 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Jun 2010 05:19:11 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: Added tag jdk7-b96 for
	changeset 208fd4451232
Message-ID: <20100611051911.4E1FC4712B@hg.openjdk.java.net>

Changeset: dac23846092a
Author:    mikejwre
Date:      2010-06-03 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/dac23846092a

Added tag jdk7-b96 for changeset 208fd4451232

! .hgtags



From lana.steuck at oracle.com  Fri Jun 11 05:24:22 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Jun 2010 05:24:22 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 59 new changesets
Message-ID: <20100611053614.AB0BC4712D@hg.openjdk.java.net>

Changeset: 4c234c13f66a
Author:    ohair
Date:      2010-05-26 20:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4c234c13f66a

6956202: Fix a few missed rebranding issues, please contact lines etc.
Reviewed-by: jjg, darcy, weijun

! make/common/Subdirs.gmk
! src/share/classes/com/sun/jarsigner/package.html
! src/share/classes/com/sun/java/util/jar/pack/package.html
! src/share/classes/com/sun/jdi/connect/package.html
! src/share/classes/com/sun/jdi/connect/spi/package.html
! src/share/classes/com/sun/jdi/event/package.html
! src/share/classes/com/sun/jdi/package.html
! src/share/classes/com/sun/jdi/request/package.html
! src/share/classes/com/sun/jmx/defaults/package.html
! src/share/classes/com/sun/jmx/interceptor/package.html
! src/share/classes/com/sun/jmx/mbeanserver/package.html
! src/share/classes/com/sun/jmx/remote/internal/package.html
! src/share/classes/com/sun/jmx/snmp/IPAcl/package.html
! src/share/classes/com/sun/jmx/snmp/agent/package.html
! src/share/classes/com/sun/jmx/snmp/daemon/package.html
! src/share/classes/com/sun/jmx/snmp/defaults/package.html
! src/share/classes/com/sun/jmx/snmp/internal/package.html
! src/share/classes/com/sun/jmx/snmp/mpm/package.html
! src/share/classes/com/sun/jmx/snmp/package.html
! src/share/classes/com/sun/jmx/snmp/tasks/package.html
! src/share/classes/com/sun/management/mgmt-overview.html
! src/share/classes/com/sun/management/package.html
! src/share/classes/com/sun/net/ssl/package.html
! src/share/classes/com/sun/rowset/providers/package.html
! src/share/classes/com/sun/servicetag/package.html
! src/share/classes/com/sun/servicetag/resources/register.html
! src/share/classes/com/sun/servicetag/resources/register_ja.html
! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html
! src/share/classes/java/security/acl/package.html
! src/share/classes/java/security/package.html
! src/share/classes/java/security/spec/package.html
! src/share/classes/java/sql/package.html
! src/share/classes/java/text/package.html
! src/share/classes/java/text/spi/package.html
! src/share/classes/java/util/jar/package.html
! src/share/classes/java/util/logging/package.html
! src/share/classes/java/util/package.html
! src/share/classes/java/util/prefs/package.html
! src/share/classes/java/util/regex/package.html
! src/share/classes/java/util/spi/package.html
! src/share/classes/java/util/zip/package.html
! src/share/classes/javax/accessibility/package.html
! src/share/classes/javax/crypto/interfaces/package.html
! src/share/classes/javax/crypto/package.html
! src/share/classes/javax/crypto/spec/package.html
! src/share/classes/javax/imageio/event/package.html
! src/share/classes/javax/imageio/metadata/doc-files/bmp_metadata.html
! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html
! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html
! src/share/classes/javax/imageio/metadata/doc-files/png_metadata.html
! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html
! src/share/classes/javax/imageio/metadata/doc-files/wbmp_metadata.html
! src/share/classes/javax/imageio/metadata/package.html
! src/share/classes/javax/imageio/package.html
! src/share/classes/javax/imageio/plugins/bmp/package.html
! src/share/classes/javax/imageio/plugins/jpeg/package.html
! src/share/classes/javax/imageio/spi/package.html
! src/share/classes/javax/imageio/stream/package.html
! src/share/classes/javax/management/build.xml
! src/share/classes/javax/management/loading/package.html
! src/share/classes/javax/management/modelmbean/package.html
! src/share/classes/javax/management/monitor/package.html
! src/share/classes/javax/management/openmbean/package.html
! src/share/classes/javax/management/package.html
! src/share/classes/javax/management/relation/package.html
! src/share/classes/javax/management/remote/package.html
! src/share/classes/javax/management/remote/rmi/package.html
! src/share/classes/javax/management/timer/package.html
! src/share/classes/javax/naming/directory/package.html
! src/share/classes/javax/naming/event/package.html
! src/share/classes/javax/naming/ldap/package.html
! src/share/classes/javax/naming/package.html
! src/share/classes/javax/naming/spi/package.html
! src/share/classes/javax/net/package.html
! src/share/classes/javax/net/ssl/package.html
! src/share/classes/javax/print/attribute/package.html
! src/share/classes/javax/print/attribute/standard/package.html
! src/share/classes/javax/print/event/package.html
! src/share/classes/javax/print/package.html
! src/share/classes/javax/rmi/ssl/package.html
! src/share/classes/javax/script/package.html
! src/share/classes/javax/security/auth/callback/package.html
! src/share/classes/javax/security/auth/kerberos/package.html
! src/share/classes/javax/security/auth/login/package.html
! src/share/classes/javax/security/auth/package.html
! src/share/classes/javax/security/auth/spi/package.html
! src/share/classes/javax/security/auth/x500/package.html
! src/share/classes/javax/security/cert/package.html
! src/share/classes/javax/security/sasl/package.html
! src/share/classes/javax/sound/midi/package.html
! src/share/classes/javax/sound/midi/spi/package.html
! src/share/classes/javax/sound/sampled/package.html
! src/share/classes/javax/sound/sampled/spi/package.html
! src/share/classes/javax/sql/package.html
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/serial/package.html
! src/share/classes/javax/sql/rowset/spi/package.html
! src/share/classes/javax/swing/border/package.html
! src/share/classes/javax/swing/colorchooser/package.html
! src/share/classes/javax/swing/event/package.html
! src/share/classes/javax/swing/filechooser/package.html
! src/share/classes/javax/swing/package.html
! src/share/classes/javax/swing/plaf/basic/package.html
! src/share/classes/javax/swing/plaf/metal/package.html
! src/share/classes/javax/swing/plaf/multi/package.html
! src/share/classes/javax/swing/plaf/nimbus/package.html
! src/share/classes/javax/swing/plaf/package.html
! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/share/classes/javax/swing/plaf/synth/package.html
! src/share/classes/javax/swing/table/package.html
! src/share/classes/javax/swing/text/html/package.html
! src/share/classes/javax/swing/text/html/parser/package.html
! src/share/classes/javax/swing/text/package.html
! src/share/classes/javax/swing/text/rtf/package.html
! src/share/classes/javax/swing/tree/package.html
! src/share/classes/javax/swing/undo/package.html
! src/share/classes/javax/xml/crypto/dom/package.html
! src/share/classes/javax/xml/crypto/dsig/dom/package.html
! src/share/classes/javax/xml/crypto/dsig/keyinfo/package.html
! src/share/classes/javax/xml/crypto/dsig/package.html
! src/share/classes/javax/xml/crypto/dsig/spec/package.html
! src/share/classes/javax/xml/crypto/package.html
! src/share/classes/org/ietf/jgss/package.html
! src/share/classes/overview-core.html
! src/solaris/classes/sun/awt/X11/keysym2ucs.h
! test/java/awt/font/LineBreakMeasurer/FRCTest.java
! test/java/awt/image/ConvolveOp/EdgeNoOpCrash.java
! test/java/beans/XMLEncoder/java_awt_Component.java
! test/java/lang/ClassLoader/getdotresource.sh
! test/java/lang/Runtime/exec/setcwd.sh
! test/java/util/ResourceBundle/Bug4083270Test.properties
! test/java/util/ResourceBundle/Bug4168625Test.java
! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java
! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java
! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java
! test/javax/swing/JTable/Test6888156.java
! test/sun/net/www/protocol/jar/getcontenttype.sh

Changeset: a6276fa6643a
Author:    ohair
Date:      2010-05-28 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a6276fa6643a

6955707: Correct addNotices.sh logic in Makefiles
6949590: exes(java.exe, javaws.exe) show Copyright Year as 2004, COMPANY as Sun
Reviewed-by: weijun, alanb

! make/common/Release.gmk
! make/common/shared/Defs.gmk
! make/java/nio/Makefile
! make/java/nio/addNotices.sh
! make/java/nio/genCharsetProvider.sh
! make/tools/manifest.mf
! src/share/classes/java/nio/channels/exceptions
! src/share/classes/java/nio/charset/exceptions
! src/share/classes/java/nio/exceptions
! src/share/classes/sun/nio/cs/standard-charsets

Changeset: 51b9e5dbc2da
Author:    mikejwre
Date:      2010-06-02 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/51b9e5dbc2da

Merge


Changeset: 050f05044e24
Author:    mikejwre
Date:      2010-06-03 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/050f05044e24

Added tag jdk7-b96 for changeset 51b9e5dbc2da

! .hgtags

Changeset: 3b909e2e2131
Author:    rupashka
Date:      2010-05-17 17:23 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3b909e2e2131

6938481: 4906607 is not fixed for NIMBUS L&F
Reviewed-by: alexp

! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java

Changeset: 57d7b80faad8
Author:    peytoia
Date:      2010-05-18 16:40 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/57d7b80faad8

6953294: Fix for 6909002 was incorrectly merged
Reviewed-by: okutsu

! make/com/sun/Makefile
- make/com/sun/inputmethods/Makefile
- make/com/sun/inputmethods/indicim/Makefile
- make/com/sun/inputmethods/thaiim/Makefile
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties

Changeset: a71c27e3ec4a
Author:    malenkov
Date:      2010-05-20 18:44 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a71c27e3ec4a

6479191: LTP: XMLEncoder does not update initialized property of GridBagConstraints type
Reviewed-by: rupashka

! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/XMLEncoder.java
! test/java/beans/XMLEncoder/java_awt_GridBagConstraints.java

Changeset: bbd5a5a4e64f
Author:    malenkov
Date:      2010-05-20 20:42 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bbd5a5a4e64f

6910490: MatteBorder JScrollpane interaction
Reviewed-by: alexp

! src/share/classes/javax/swing/border/MatteBorder.java
+ test/javax/swing/border/Test6910490.html
+ test/javax/swing/border/Test6910490.java

Changeset: 3a19541d8119
Author:    alexp
Date:      2010-05-21 22:04 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3a19541d8119

6953396: javax.swing.plaf.basic.BasicViewportUI.uninstallDefaults() is not called when UI is uninstalled
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicViewportUI.java
+ test/javax/swing/JViewport/6953396/bug6953396.java

Changeset: a0c6dae0f173
Author:    lana
Date:      2010-05-21 17:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a0c6dae0f173

Merge


Changeset: 3de717f6ddab
Author:    alexp
Date:      2010-05-25 20:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3de717f6ddab

6786238: api/javax_swing/DefaultDesktopManager/descriptions.html#xxxFrame Fails with NPE since 6u12 b02
Reviewed-by: rupashka

! src/share/classes/javax/swing/DefaultDesktopManager.java

Changeset: 1297a41dbb47
Author:    alexp
Date:      2010-05-25 20:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1297a41dbb47

6937798: Nimbus: Issues with JTable grid
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java
+ test/javax/swing/JTable/6937798/bug6937798.java

Changeset: 8d59b361635f
Author:    alexp
Date:      2010-05-25 20:39 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8d59b361635f

6768387: REGRESSION: JTable no longer serializable
Reviewed-by: rupashka

! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java
+ test/javax/swing/JTable/6768387/bug6768387.java

Changeset: d540eeccf73a
Author:    alexp
Date:      2010-05-25 20:54 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d540eeccf73a

6884066: JTableHeader listens mouse in disabled state and doesn't work when not attached to a table
Reviewed-by: rupashka

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java
! src/share/classes/sun/swing/SwingUtilities2.java
+ test/javax/swing/JTableHeader/6884066/bug6884066.java

Changeset: fc1ac6ea933c
Author:    peterz
Date:      2010-05-26 20:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fc1ac6ea933c

6632959: swing html parser doesn't know &euro; or &rsaquo;
Reviewed-by: alexp

! make/javax/swing/FILES.gmk
! make/javax/swing/Makefile
- src/share/classes/javax/swing/text/html/parser/html32.bdtd

Changeset: e821a3568b0a
Author:    rupashka
Date:      2010-05-26 22:02 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e821a3568b0a

6925473: REGRESSION: JOptionPane in dialog is full-screen height
Reviewed-by: peterz

! src/share/classes/javax/swing/text/WrappedPlainView.java
+ test/javax/swing/JTextArea/6925473/bug6925473.java
+ test/javax/swing/JTextArea/6940863/bug6940863.java
! test/javax/swing/JTextArea/Test6593649.java

Changeset: 824b0f8b68f6
Author:    peterz
Date:      2010-05-28 13:31 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/824b0f8b68f6

6929507: Build error on file swing.plaf.synth.SynthUI
Reviewed-by: rupashka

! make/common/Release.gmk
! make/tools/sharing/classlist.linux
! make/tools/sharing/classlist.solaris

Changeset: e2b1bab101d2
Author:    peterz
Date:      2010-05-28 13:32 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e2b1bab101d2

6954231: SynthTextPaneUI.installUI() doesn't set component to opaque even if prop was not set by client progr
Reviewed-by: alexp

! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java

Changeset: 9b247a6290a4
Author:    alexp
Date:      2010-05-28 19:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9b247a6290a4

6889007: No resize cursor during hovering mouse over JTable
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java
+ test/javax/swing/JTableHeader/6889007/bug6889007.java

Changeset: 82524b068f77
Author:    alexp
Date:      2010-05-28 19:55 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/82524b068f77

6670274: Incorrect tab titles for JTabbedPane if using HTML (BasicTabbedPanelUI problem)
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java
+ test/javax/swing/JTabbedPane/6670274/bug6670274.java

Changeset: be03f9a285f0
Author:    lana
Date:      2010-06-01 14:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/be03f9a285f0

Merge

! make/com/sun/Makefile
! make/common/Release.gmk
! make/javax/swing/FILES.gmk
! make/javax/swing/Makefile
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java
! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/XMLEncoder.java
! src/share/classes/javax/swing/DefaultDesktopManager.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/border/MatteBorder.java
! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
! src/share/classes/javax/swing/plaf/basic/BasicViewportUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java
! src/share/classes/javax/swing/text/WrappedPlainView.java
! src/share/classes/sun/swing/SwingUtilities2.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java
! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java
! test/java/beans/XMLEncoder/java_awt_GridBagConstraints.java
! test/javax/swing/JTextArea/Test6593649.java

Changeset: 18ee3c1b9143
Author:    lana
Date:      2010-06-01 21:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/18ee3c1b9143

Merge

- make/com/sun/inputmethods/Makefile
- make/com/sun/inputmethods/indicim/Makefile
- make/com/sun/inputmethods/thaiim/Makefile
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties
- src/share/classes/javax/swing/text/html/parser/html32.bdtd

Changeset: 05c9ff89bcdc
Author:    mchung
Date:      2010-05-12 14:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/05c9ff89bcdc

6951661: Eliminate jvmstat dependency on sun.management.counter
Summary: jvmstat keeps its own copy of Units and Variability class
Reviewed-by: alanb

! src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java
! src/share/classes/sun/jvmstat/monitor/Monitor.java
+ src/share/classes/sun/jvmstat/monitor/Units.java
+ src/share/classes/sun/jvmstat/monitor/Variability.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java
! src/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java
! src/share/classes/sun/tools/jstat/ExpressionResolver.java
! src/share/classes/sun/tools/jstat/JStatLogger.java
! src/share/classes/sun/tools/jstat/Jstat.java

Changeset: 2d54e4cae441
Author:    ohair
Date:      2010-05-12 21:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2d54e4cae441

6943915: Adjust jdk/test/Makefile to deal with .dll and .so libraries needing execute permissions
Summary: And adjustments to test problem list.
Reviewed-by: jjg

! test/Makefile
! test/ProblemList.txt
! test/java/lang/ProcessBuilder/Basic.java
! test/java/lang/Runtime/exec/ExecWithDir.java

Changeset: f6b72c9023f4
Author:    ptisnovs
Date:      2010-05-13 10:11 +0200
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f6b72c9023f4

6951887: Wrong redirection useage in test sun/nio/cs/Test4200310.sh
Summary: Testcase correction.
Reviewed-by: sherman

! test/sun/nio/cs/Test4200310.sh

Changeset: aa1b15bdbf2b
Author:    sherman
Date:      2010-05-13 21:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/aa1b15bdbf2b

6951064: Typo in javadoc for ZipException ctors
Summary: fixed the doc typo
Reviewed-by: martin

! src/share/classes/java/util/zip/ZipException.java

Changeset: e85e03ef61c1
Author:    martin
Date:      2010-05-13 21:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e85e03ef61c1

6952330: Fix for 6933217 broke contract of StringBuffer.ensureCapacity
Summary: make sure to grow with size => size * 2 + 2
Reviewed-by: dholmes, chegar, ohair

! src/share/classes/java/lang/AbstractStringBuilder.java
+ test/java/lang/StringBuffer/Capacity.java

Changeset: ac74c3b96e49
Author:    sherman
Date:      2010-05-14 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ac74c3b96e49

6952701: Use http://www.ietf.org/rfc for rfc references in jdk public APIs
Summary: replace www.isi.edu/in-notes with www.ietf.org/rfc
Reviewed-by: martin

! src/share/classes/java/util/zip/package.html
! src/share/classes/javax/naming/event/EventDirContext.java
! src/share/classes/javax/naming/ldap/Control.java
! src/share/classes/javax/naming/ldap/ControlFactory.java
! src/share/classes/javax/naming/ldap/ExtendedRequest.java
! src/share/classes/javax/naming/ldap/ExtendedResponse.java
! src/share/classes/javax/naming/ldap/UnsolicitedNotification.java
! src/share/classes/javax/naming/ldap/UnsolicitedNotificationListener.java
! src/share/classes/javax/print/DocFlavor.java

Changeset: 2fb3d7dbaa32
Author:    sherman
Date:      2010-05-14 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2fb3d7dbaa32

4263582: RFE: GZIPInputStream throws IOException on non-gzipped data
Summary: throw ZipException instead of IOException
Reviewed-by: martin

! src/share/classes/java/util/zip/GZIPInputStream.java

Changeset: 91bcd8fc04f2
Author:    sherman
Date:      2010-05-16 21:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/91bcd8fc04f2

4465490: Suspicious about double-check locking idiom being used in the code
Summary: to use volatile for the double-checked object
Reviewed-by: weijun

! src/share/classes/java/util/jar/JarVerifier.java

Changeset: 43f83a2cf5b5
Author:    sherman
Date:      2010-05-17 12:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/43f83a2cf5b5

4813885: RFE: GZIPOutputStream should implement flush using Z_SYNC_FLUSH
Summary: Added new constructors to allow flush() work in Z_SYNC_FLUSH mode
Reviewed-by: martin

! src/share/classes/java/util/zip/GZIPOutputStream.java
! test/java/util/zip/InflateIn_DeflateOut.java

Changeset: 1e0c3e864fb1
Author:    sherman
Date:      2010-05-17 16:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1e0c3e864fb1

4853493: GZIPOutputStream passes a reference to a private array into an untrusted method
Summary: create a new header byte array for each header writeout
Reviewed-by: martin

! src/share/classes/java/util/zip/GZIPOutputStream.java

Changeset: b3466e2c3819
Author:    mchung
Date:      2010-05-18 13:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b3466e2c3819

6951599: Rename package of security tools for modularization
Summary: Move PolicyTool to sun.security.tools.policytool package
Reviewed-by: weijun

! make/modules/modules.config
! make/sun/security/tools/Makefile
- src/share/classes/sun/security/tools/PolicyTool.java
+ src/share/classes/sun/security/tools/policytool/PolicyTool.java

Changeset: 33409b9b0f49
Author:    sherman
Date:      2010-05-18 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/33409b9b0f49

6945564: Unicode script support in Character class
6948903: Make Unicode scripts available for use in regular expressions
Summary: added Unicode script suport
Reviewed-by: martin

! make/java/java/FILES_java.gmk
! make/java/java/Makefile
+ make/tools/UnicodeData/Scripts.txt
+ make/tools/src/build/tools/generatecharacter/CharacterName.java
+ make/tools/src/build/tools/generatecharacter/CharacterScript.java
! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
! src/share/classes/java/lang/Character.java
+ src/share/classes/java/lang/CharacterName.java
! src/share/classes/java/util/regex/Pattern.java
+ test/java/lang/Character/CheckScript.java
+ test/java/lang/Character/Scripts.txt
! test/java/util/regex/RegExTest.java

Changeset: 70e25a57fd02
Author:    ohair
Date:      2010-05-20 13:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/70e25a57fd02

6954064: Fix the windows arch settings in the makefiles and chmod logic in test/Makefile
Reviewed-by: wetmore

! make/common/shared/Platform.gmk
! test/Makefile
! test/ProblemList.txt

Changeset: 67ea299d5501
Author:    michaelm
Date:      2010-05-21 07:29 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/67ea299d5501

6773270: java.net.URI fails to escape \u0000
Summary: check for \u0000
Reviewed-by: alanb

! src/share/classes/java/net/URI.java
! test/java/net/URI/Test.java

Changeset: d01726854317
Author:    weijun
Date:      2010-05-24 09:28 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d01726854317

6948803: CertPath validation regression caused by SHA1 replacement root and MD2 disable feature
Reviewed-by: xuelei, mullan

! src/share/classes/sun/security/validator/PKIXValidator.java
+ test/sun/security/validator/CertReplace.java
+ test/sun/security/validator/certreplace.sh

Changeset: c36617d0dae7
Author:    weijun
Date:      2010-05-24 09:28 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c36617d0dae7

6954621: small error in 6948909
Reviewed-by: xuelei

! src/share/classes/sun/security/tools/JarSigner.java

Changeset: ff9cc9789bb3
Author:    weijun
Date:      2010-05-24 09:37 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ff9cc9789bb3

6882687: KerberosTime too imprecise
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/internal/KerberosTime.java
+ test/sun/security/krb5/MicroTime.java

Changeset: 625c75559b0d
Author:    weijun
Date:      2010-05-24 09:37 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/625c75559b0d

6948781: CertificateFactory.generateCertificate doesn't throw CertificateException for malformed certificate
Reviewed-by: mullan

! src/share/classes/sun/security/provider/X509Factory.java
+ test/java/security/cert/CertificateFactory/openssl/BadFooter.java

Changeset: ba95fd03440b
Author:    weijun
Date:      2010-05-24 10:05 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ba95fd03440b

6932525: Incorrect encryption types of KDC_REQ_BODY of AS-REQ with pre-authentication
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/KrbAsReq.java
! test/sun/security/krb5/auto/KDC.java

Changeset: 41a5722e6e10
Author:    sherman
Date:      2010-05-24 00:39 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/41a5722e6e10

4691425: GZIPInputStream fails to read concatenated .gz files
Summary: to support concatenated .gz streams
Reviewed-by: martin

! src/share/classes/java/util/zip/GZIPInputStream.java
+ test/java/util/zip/GZIP/GZIPInputStreamRead.java

Changeset: dd41a79890c3
Author:    lana
Date:      2010-05-24 09:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/dd41a79890c3

Merge

! make/common/shared/Platform.gmk

Changeset: 6df25b528926
Author:    sherman
Date:      2010-05-24 15:20 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6df25b528926

4690407: JAR tool: option -i can't be combined with other options
Summary: -i can't combined with cxut, do sanity check on options
Reviewed-by: martin

! src/share/classes/sun/tools/jar/Main.java

Changeset: d1cf79e27365
Author:    sherman
Date:      2010-05-24 16:41 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d1cf79e27365

Merge


Changeset: 2306564dea3a
Author:    weijun
Date:      2010-05-25 18:20 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2306564dea3a

6948287: KDC test strange knvo
Reviewed-by: xuelei

! test/sun/security/krb5/auto/KDC.java

Changeset: dfa98add4ad0
Author:    jjg
Date:      2010-05-25 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/dfa98add4ad0

6934615: Relative classpaths in jarfile manifests are handled inefficiently by rmic
Reviewed-by: darcy

! src/share/classes/sun/rmi/rmic/BatchEnvironment.java
! test/sun/rmi/rmic/manifestClassPath/run.sh

Changeset: d5939d20b762
Author:    weijun
Date:      2010-05-27 17:24 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d5939d20b762

6955783: ServiceUnavailableException caught even the secondary DNS is available
Reviewed-by: vinnie

! src/share/classes/com/sun/jndi/dns/DnsClient.java

Changeset: 0454cb04a407
Author:    andrew
Date:      2010-05-28 16:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0454cb04a407

6956840: (ch) Rawtype warning when compiling sun.nio.ch.CompletedFuture
Summary: Add missing generic type to CompletedFuture construction and remove unneeded SuppressWarnings annotations.
Reviewed-by: alanb

! src/share/classes/sun/nio/ch/CompletedFuture.java

Changeset: 0f58be815a2e
Author:    andrew
Date:      2010-05-28 17:01 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0f58be815a2e

Merge


Changeset: 6bc450d87125
Author:    lana
Date:      2010-05-28 12:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6bc450d87125

Merge

! make/common/shared/Platform.gmk
! make/java/java/FILES_java.gmk
! make/java/java/Makefile
! make/modules/modules.config
! make/sun/security/tools/Makefile
! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
! src/share/classes/com/sun/jndi/dns/DnsClient.java
! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/net/URI.java
! src/share/classes/java/util/jar/JarVerifier.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/java/util/zip/GZIPInputStream.java
! src/share/classes/java/util/zip/GZIPOutputStream.java
! src/share/classes/java/util/zip/ZipException.java
! src/share/classes/java/util/zip/package.html
! src/share/classes/javax/naming/event/EventDirContext.java
! src/share/classes/javax/naming/ldap/Control.java
! src/share/classes/javax/naming/ldap/ControlFactory.java
! src/share/classes/javax/naming/ldap/ExtendedRequest.java
! src/share/classes/javax/naming/ldap/ExtendedResponse.java
! src/share/classes/javax/naming/ldap/UnsolicitedNotification.java
! src/share/classes/javax/naming/ldap/UnsolicitedNotificationListener.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java
! src/share/classes/sun/jvmstat/monitor/Monitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java
! src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java
! src/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java
! src/share/classes/sun/nio/ch/CompletedFuture.java
! src/share/classes/sun/rmi/rmic/BatchEnvironment.java
! src/share/classes/sun/security/krb5/KrbAsReq.java
! src/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/share/classes/sun/security/provider/X509Factory.java
! src/share/classes/sun/security/tools/JarSigner.java
! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/validator/PKIXValidator.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jstat/ExpressionResolver.java
! src/share/classes/sun/tools/jstat/JStatLogger.java
! src/share/classes/sun/tools/jstat/Jstat.java
! test/Makefile
! test/ProblemList.txt
! test/java/lang/ProcessBuilder/Basic.java
! test/java/lang/Runtime/exec/ExecWithDir.java
! test/java/net/URI/Test.java
! test/java/util/regex/RegExTest.java
! test/java/util/zip/InflateIn_DeflateOut.java
! test/sun/nio/cs/Test4200310.sh
! test/sun/rmi/rmic/manifestClassPath/run.sh
! test/sun/security/krb5/auto/KDC.java

Changeset: f3189453d134
Author:    weijun
Date:      2010-06-01 10:52 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f3189453d134

6950931: test fails on windows sun/security/tools/jarsigner/crl.sh
Reviewed-by: wetmore, xuelei

! test/sun/security/tools/jarsigner/crl.sh

Changeset: 31a7a323a604
Author:    lana
Date:      2010-06-01 21:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/31a7a323a604

Merge

- src/share/classes/sun/security/tools/PolicyTool.java

Changeset: 962608ee8cdb
Author:    lana
Date:      2010-06-07 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/962608ee8cdb

6888130: SwingSet2: Demo is not launching and throwing NPE.
Reviewed-by: prr

! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java

Changeset: 7140b5759b63
Author:    lana
Date:      2010-06-07 17:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7140b5759b63

Merge

- make/com/sun/inputmethods/Makefile
- make/com/sun/inputmethods/indicim/Makefile
- make/com/sun/inputmethods/thaiim/Makefile
! make/common/Release.gmk
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties
! src/share/classes/java/util/zip/package.html
- src/share/classes/javax/swing/text/html/parser/html32.bdtd
- src/share/classes/sun/security/tools/PolicyTool.java

Changeset: fb56f86642d6
Author:    andrew
Date:      2010-06-03 18:49 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fb56f86642d6

6958257: Add support for alpha
Summary: Allow the Zero port to be built on alpha architectures
Reviewed-by: ohair

! make/common/Defs-linux.gmk

Changeset: be0d055db574
Author:    ohair
Date:      2010-06-07 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/be0d055db574

6959116: Fix regression in make/jdk_generic_profile.sh (PROCESSOR_IDENTIFIER)
Reviewed-by: alanb

! make/jdk_generic_profile.sh

Changeset: b1903d7528d3
Author:    mikejwre
Date:      2010-06-09 18:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b1903d7528d3

Merge


Changeset: ae887ea4c772
Author:    lana
Date:      2010-06-10 18:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ae887ea4c772

Merge

- make/com/sun/inputmethods/Makefile
- make/com/sun/inputmethods/indicim/Makefile
- make/com/sun/inputmethods/thaiim/Makefile
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties
- src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java
- src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor
- src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties
- src/share/classes/javax/swing/text/html/parser/html32.bdtd
- src/share/classes/sun/security/tools/PolicyTool.java



From lana.steuck at oracle.com  Fri Jun 11 05:54:10 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Jun 2010 05:54:10 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 12 new changesets
Message-ID: <20100611055432.8A38047135@hg.openjdk.java.net>

Changeset: 9c2d50e46e31
Author:    ohair
Date:      2010-05-26 20:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/9c2d50e46e31

6956202: Fix a few missed rebranding issues, please contact lines etc.
Reviewed-by: darcy, jjg, weijun

! src/share/classes/com/sun/javadoc/package.html
! src/share/classes/com/sun/mirror/overview.html
! src/share/classes/com/sun/source/tree/DisjointTypeTree.java
! src/share/classes/javax/lang/model/overview.html
! test/tools/apt/mirror/declaration/pkg1/pkg2/package.html

Changeset: 89cd267c2167
Author:    mikejwre
Date:      2010-06-02 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/89cd267c2167

Merge


Changeset: aecce211bc6f
Author:    mikejwre
Date:      2010-06-03 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/aecce211bc6f

Added tag jdk7-b96 for changeset 89cd267c2167

! .hgtags

Changeset: ebf09be0222c
Author:    jjg
Date:      2010-05-13 11:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ebf09be0222c

6952188: update timeout for langtools jtreg tests on JPRT
Reviewed-by: ohair

! test/Makefile

Changeset: e9ef849ae0ed
Author:    mcimadamore
Date:      2010-05-19 16:41 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/e9ef849ae0ed

6880344: Recursive type parameters do not compile
Summary: Issue in type-variable substitution causes valid code to be rejected
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/typevars/T6880344.java

Changeset: 2881b376a689
Author:    mcimadamore
Date:      2010-05-19 16:42 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2881b376a689

6946618: sqe test fails: javac/generics/NewOnTypeParm  in pit jdk7 b91 in all platforms.
Summary: Bad cast to ClassType in the new diamond implementation fails if the target type of the instance creation expression is a type-variable
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/generics/6946618/T6946618a.java
+ test/tools/javac/generics/6946618/T6946618a.out
+ test/tools/javac/generics/6946618/T6946618b.java
+ test/tools/javac/generics/6946618/T6946618b.out
+ test/tools/javac/generics/6946618/T6946618c.java
+ test/tools/javac/generics/6946618/T6946618c.out

Changeset: eb849389ae2c
Author:    mcimadamore
Date:      2010-05-19 16:43 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/eb849389ae2c

6948381: javac Null Pointer Exception in Types.makeCompoundType
Summary: Race condition between symbol completion and attribution of import statements causes NPE when creating intersection type
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/6948381/T6948381.java
+ test/tools/javac/6948381/npe/A.java
+ test/tools/javac/6948381/npe/B.java

Changeset: 1d587ef8bf56
Author:    mcimadamore
Date:      2010-05-19 16:43 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/1d587ef8bf56

6951833: latest diamond implementation generates spurious raw type warnings
Summary: Raw warning checks should be disabled in the presence of a diamond AST node
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/diamond/T6951833.java

Changeset: e9d66d392a8d
Author:    jjg
Date:      2010-05-21 17:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/e9d66d392a8d

6954901: langtools/test/Makefile should check for bin/javac(.exe) instead of lib/tools.jar
Reviewed-by: ohair

! test/Makefile

Changeset: 16efe627290e
Author:    lana
Date:      2010-05-24 09:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/16efe627290e

Merge


Changeset: 593a59e40bdb
Author:    lana
Date:      2010-05-28 12:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/593a59e40bdb

Merge

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java

Changeset: c0a41294297e
Author:    lana
Date:      2010-06-07 17:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c0a41294297e

Merge




From neugens at limasoftware.net  Fri Jun 11 07:51:32 2010
From: neugens at limasoftware.net (Mario Torre)
Date: Fri, 11 Jun 2010 09:51:32 +0200
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <4C11590E.7040308@oracle.com>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica>
	<4BF325E8.6080301@oracle.com> <1274257734.1895.8.camel@moonlight>
	<4BF4594B.8070400@oracle.com> <1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight> <1275070336.2300.6.camel@galactica>
	<4C11590E.7040308@oracle.com>
Message-ID: <1276242692.2438.13.camel@galactica>

Il giorno gio, 10/06/2010 alle 14.28 -0700, Phil Race ha scritto:
> I've root-caused this although its still not clear what's the ideal answer,
> the simplest and safest may be Mario's proposed fix here from 5/5/2010 :

> ....

Hi Phil!

Thanks for the long explanation, everything makes perfect sense to me
now.

> Mario's concern about hinting isn't founded. It doesn't matter.

I thought about that, but I didn't have so much experience with fonts to
be so sure. This makes perfectly sense to me as well now.

> So I think (bit of hand waving)
> 1) Implement Mario's fix which will solve negative leading

Yeah! :)

I'm not at home now, I'll be back on Monday evening, I will make sure
the fix fits in the latest j2d code drop, then we can go through the
committing process again. Of course if there's a rush somebody else can
commit on my behalf.

I believe this specific part should also go to OpenJDK 6, what are your
thoughts about that (NetBeans looks really awful)?

> 2) Separately consider the larger change to
>    a) tighten up the height we reportywith the consequence that its common that
>    getAscent()+getDescent()+getLeading() > getHeight()
>    b) Fix up everywhere in the JDK that assumes otherwise ..
>   (a) and (b) ought to be as much as possible in the same commit
>    which means its a bigger job but still with follow-up inevitably needed.

I'll go through some of those myself in the next days. Of course, I
can't help on Sun/Oracle customers specific problems, but I can surely
help on the OpenJDK ones. Perhaps this is a bit too much risk for jdk 6
anyway, but it can be surely done for 7.

Cheers and thanks again for looking into it!
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/



From dlila at redhat.com  Mon Jun 14 21:04:46 2010
From: dlila at redhat.com (Denis Lila)
Date: Mon, 14 Jun 2010 17:04:46 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length
In-Reply-To: <1912367199.205001276006221680.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <1901917784.92751276549486770.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

I can see one slight problem with this.
moveTo will check whether "if (prev == LINE_TO) {" in line 488.
This should be changed to "if (prev == LINE_TO || atLeastOneLine) {".
If this is not done, and if there are many moveTo's, each followed by
a lineTo to a line of 0 length, no end caps will be drawn for any of
the lines except perhaps the last lineTo.

See bug 197: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197
for reproducers, effects, and some more discussion on this.

Regards,
Denis Lila.

----- Original Message -----
From: "jon vanalten" <jon.vanalten at redhat.com>
To: 2d-dev at openjdk.java.net
Sent: Tuesday, June 8, 2010 10:10:21 AM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length

<BUMP>

Hi, I sent this a while ago.  Wondering if anyone has any feedback?

thanks in advance,

jon



----- "jon vanalten" <jon.vanalten at redhat.com> wrote:

> Hi,
> 
> I am new to this list, hopefully it is okay that I post a potential
> fix to a very minor rendering bug.
> 
> I've been looking at a bug reported downstream at IcedTea:
> 
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=383
> 
> To summarize, if a line is drawn via Graphics2D.drawLine() of zero
> length but thickness greater than 1, the endcap decorations are not
> rendered.  This is because the sun.java2d.pisces.Stroker class ignores
> such line segments.  This is ideal in most situations drawing complex
> shapes, but when such a line segment is the entire shape the end
> result nothing at all is rendered.  The closed-source Sun JDK
> implementation does render endcap decorations in this case, and the
> documentation of the BasicStroke class related to this suggests that
> they should be rendered.
> 
> I've put together a (possibly straw-man) fix.  Please do pick it
> apart, I have never looked at the graphics implementation before
> trying to tackle this bug.  I basically add a boolean to indicate that
> the finish() step should be taken if *any* lineTo() call has occurred,
> and in the finish() step detect if there are any segments and if no
> manually draw in the caps (while allowing normal behaviour in other
> cases).
> 
> See webrev at:
> 
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev/
> (or download)
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev.zip
> 
> Your comments are appreciated.
> 
> cheers,
> 
> jon


From linuxhippy at gmail.com  Tue Jun 15 13:40:22 2010
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 15 Jun 2010 15:40:22 +0200
Subject: [OpenJDK 2D-Dev] 2 small xrender fixes
Message-ID: <AANLkTinOMS8Su9Qk-Zp5lQN0Sdx7knuUAnSvgblFvjhI@mail.gmail.com>

Hi,

I would like to get two (very small) changes to the xrender-pipeline in:

1. http://93.83.133.214/ignore-whitespace-width.zip deals with the
fact that the closed-source
font rasterizer seems to generate width=65535 for whitespaces, which
resuts in software fallbacks.
Granted with height=0 rendering should be completly omited by the X
server, but as it seems it isnt.

2. http://93.83.133.214/synchronize-native-cairo-ops.zip
synchronize-native-cairo-ops synchronizes access to Jules's native
functions.
There seems to be a race somewhere in cairo and I wasn't able to hunt
it down, so synchronizing is the best I can do for now.

Do I need to create two different bug-reports? Is OpenJDK Bugzilla enough?


From ahughes at redhat.com  Tue Jun 15 14:56:35 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Tue, 15 Jun 2010 15:56:35 +0100
Subject: [OpenJDK 2D-Dev] 2 small xrender fixes
In-Reply-To: <AANLkTinOMS8Su9Qk-Zp5lQN0Sdx7knuUAnSvgblFvjhI@mail.gmail.com>
References: <AANLkTinOMS8Su9Qk-Zp5lQN0Sdx7knuUAnSvgblFvjhI@mail.gmail.com>
Message-ID: <AANLkTinQw4FROpNp5EWoQNgiv-EajrAMm9q_kU5rdtJZ@mail.gmail.com>

On 15 June 2010 14:40, Clemens Eisserer <linuxhippy at gmail.com> wrote:
> Hi,
>
> I would like to get two (very small) changes to the xrender-pipeline in:
>
> 1. http://93.83.133.214/ignore-whitespace-width.zip deals with the
> fact that the closed-source
> font rasterizer seems to generate width=65535 for whitespaces, which
> resuts in software fallbacks.
> Granted with height=0 rendering should be completly omited by the X
> server, but as it seems it isnt.
>
> 2. http://93.83.133.214/synchronize-native-cairo-ops.zip
> synchronize-native-cairo-ops synchronizes access to Jules's native
> functions.
> There seems to be a race somewhere in cairo and I wasn't able to hunt
> it down, so synchronizing is the best I can do for now.
>
> Do I need to create two different bug-reports? Is OpenJDK Bugzilla enough?
>

You need a Sun bug ID (i.e. bugs.sun.com) for each, but it's quicker
if an Oracle developer creates one.  Just ask for one when the patch
is approved.

It would be easier to read these if there were posted as patches or
webrevs, not zips.

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From dlila at redhat.com  Tue Jun 15 20:53:31 2010
From: dlila at redhat.com (Denis Lila)
Date: Tue, 15 Jun 2010 16:53:31 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for uniformly scaled dashed lines.
In-Reply-To: <2106605058.196921276634948314.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <736740737.197661276635211142.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello.

I think I have a fix for this bug: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=504

The problem is caused by the "symmetric" variable in pisces/Dasher.java.
symmetric is set to (m00 == m11 && m10 == -m01), and never changed.

It is only used in one place (in lineTo) to simplify the computation of
the length of the line before an affine transformation A was applied to it.

This is why it causes a problem:
If A = [[a00, a01], [a10, a11]] and (x,y) is a point obtained by applying
A to some other point (x',y'), then what we want is the length of the vector
(x',y'), which is ||Ainv*(x,y)||. Ainv = (1/det(A)) * [[a11, -a01],[-a10, a00]],
so, after some calculations, ||Ainv*(x,y)|| ends up being equal to
sqrt(x^2*(a11^2 + a10^2) + y^2*(a00^2 + a01^2) - x*y*(a11*a01 + a00*a10)) * 1/|det(A)|.
If symmetric==true, this simplifies to:
sqrt((a11^2 + a01^2) * (x^2 + y^2)) * 1/|det(A)|, and
|det(A)| = a11^2 + a01^2, so, the final answer is:
sqrt((x^2 + y^2)) / sqrt(det(A)). Therefore the problem in Dasher.java
is that it divides by det(A), not sqrt(det(A)).

My fix for this was to remove the "symmetric" special case. Another possible fix
would have been to introduce an instance "sqrtldet" and set it to sqrt(det(A)),
and divide by that instead of det(A). This didn't seem worth it, because the only
benefit we gain by having the "symmetric" variable is to save 3 multiplications
and 1 division per iteration of the while(true) loop, at the expense of making the 
code more complex, harder to read, introducing more opportunity for bugs, and adding
hundreds of operations of overhead (since PiscesMath.sqrt would have to be called to
initialize sqrtldet).

To make up for this slight performance loss I have moved the code that computes
the transformed dash vectors outside of the while loop, since they are constant
and they only need to be computed once for any one line.
Moreover, computing the constant dash vectors inside the loop causes
them to not really be constant (since they're computed by dividing numbers that
aren't constant). This can cause irregularities in dashes (see comment 14 in
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197).

I would very much appreciate any comments/suggestions.

Thank you,
Denis Lila.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug504fix.patch
Type: text/x-patch
Size: 4637 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100615/14acfa2c/bug504fix.patch>

From ahughes at redhat.com  Wed Jun 16 15:18:42 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Wed, 16 Jun 2010 16:18:42 +0100
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] Fix for bug where long dashed
	lines can make graphics go black.
In-Reply-To: <1645847476.649001276123775388.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1158471715.648971276123728748.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
	<1645847476.649001276123775388.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <AANLkTikjLhgvRaTY_zmUiJdghM-ubHg0NtGqJ7AcdETl@mail.gmail.com>

On 9 June 2010 23:49, Denis Lila <dlila at redhat.com> wrote:
> Hello.
>
> I think I have a fix for this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=597227
>
> The bug was caused by a few integer overflows in sun/java2d/pisces/Dasher.java
> and sun/java2d/pisces/Stroker.java which would cause the whole container to
> fill up with whatever colour the line had. Dasher.java was prone to 2 overflows:
> one when computing the x and y coordinate lengths of the line at hand, and
> another which actually happened in PiscesMath.hypot(int,int). I fixed these
> two by turning the variables into longs and using PiscesMath.hypot(long,long).
>
> Stroker.java was only prone to overflows when drawing end caps or when adding
> offsets to points. I fixed these by making sure lineTo and moveTo never moved
> too close to the boundaries set by Integer.MAX_VALUE and Integer.MIN_VALUE.
>
> I welcome any feedback.
>
> Thank you,
> Denis Lila.

Webrev against 2d: http://cr.openjdk.java.net/~andrew/rh597227/

Do you have a reproducer for this?  It would help if that was included
as a JTreg test.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From neugens at limasoftware.net  Wed Jun 16 15:43:57 2010
From: neugens at limasoftware.net (Mario Torre)
Date: Wed, 16 Jun 2010 17:43:57 +0200
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <1276242692.2438.13.camel@galactica>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica>
	<4BF325E8.6080301@oracle.com> <1274257734.1895.8.camel@moonlight>
	<4BF4594B.8070400@oracle.com> <1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight> <1275070336.2300.6.camel@galactica>
	<4C11590E.7040308@oracle.com>  <1276242692.2438.13.camel@galactica>
Message-ID: <1276703037.4279.37.camel@galactica>

Il giorno ven, 11/06/2010 alle 09.51 +0200, Mario Torre ha scritto:
> Il giorno gio, 10/06/2010 alle 14.28 -0700, Phil Race ha scritto:
> > I've root-caused this although its still not clear what's the ideal answer,
> > the simplest and safest may be Mario's proposed fix here from 5/5/2010 :

I've applied the patch to the latest OpenJDK drop and it compiles and
work fine.

I'm now downloading the j2d repository, I think I need a bug id before
committing, can somebody please create one for me?

Cheers,
Mario
-- 
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas GmbH, Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards: http://endsoftpatents.org/

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/



From philip.race at oracle.com  Wed Jun 16 16:37:46 2010
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Jun 2010 09:37:46 -0700
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <1276703037.4279.37.camel@galactica>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica> <4BF325E8.6080301@oracle.com>
	<1274257734.1895.8.camel@moonlight> <4BF4594B.8070400@oracle.com>
	<1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight>
	<1275070336.2300.6.camel@galactica> <4C11590E.7040308@oracle.com>
	<1276242692.2438.13.camel@galactica>
	<1276703037.4279.37.camel@galactica>
Message-ID: <4C18FDDA.9010708@oracle.com>

6961732: FontMetrics.getLeading() may be negative in freetype-based 
OpenJDK builds

-phil.

On 6/16/2010 8:43 AM, Mario Torre wrote:
> Il giorno ven, 11/06/2010 alle 09.51 +0200, Mario Torre ha scritto:
>    
>> Il giorno gio, 10/06/2010 alle 14.28 -0700, Phil Race ha scritto:
>>      
>>> I've root-caused this although its still not clear what's the ideal answer,
>>> the simplest and safest may be Mario's proposed fix here from 5/5/2010 :
>>>        
> I've applied the patch to the latest OpenJDK drop and it compiles and
> work fine.
>
> I'm now downloading the j2d repository, I think I need a bug id before
> committing, can somebody please create one for me?
>
> Cheers,
> Mario
>    



From neugens at limasoftware.net  Wed Jun 16 16:52:49 2010
From: neugens at limasoftware.net (Mario Torre)
Date: Wed, 16 Jun 2010 18:52:49 +0200
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <4C18FDDA.9010708@oracle.com>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica>
	<4BF325E8.6080301@oracle.com> <1274257734.1895.8.camel@moonlight>
	<4BF4594B.8070400@oracle.com> <1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight> <1275070336.2300.6.camel@galactica>
	<4C11590E.7040308@oracle.com> <1276242692.2438.13.camel@galactica>
	<1276703037.4279.37.camel@galactica>  <4C18FDDA.9010708@oracle.com>
Message-ID: <1276707169.4279.50.camel@galactica>

Il giorno mer, 16/06/2010 alle 09.37 -0700, Phil Race ha scritto:
> 6961732: FontMetrics.getLeading() may be negative in freetype-based 
> OpenJDK builds
> 
> -phil.
> 

Hi Phil,

Thank you, I'm still compiling the j2d forest, then I'll push to the
2d-gate.

Thanks,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/



From mario.torre at aicas.com  Wed Jun 16 17:40:53 2010
From: mario.torre at aicas.com (Mario Torre)
Date: Wed, 16 Jun 2010 19:40:53 +0200
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <1276707169.4279.50.camel@galactica>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica>
	<4BF325E8.6080301@oracle.com> <1274257734.1895.8.camel@moonlight>
	<4BF4594B.8070400@oracle.com> <1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight> <1275070336.2300.6.camel@galactica>
	<4C11590E.7040308@oracle.com> <1276242692.2438.13.camel@galactica>
	<1276703037.4279.37.camel@galactica>  <4C18FDDA.9010708@oracle.com>
	<1276707169.4279.50.camel@galactica>
Message-ID: <1276710053.30565.1.camel@galactica>

Il giorno mer, 16/06/2010 alle 18.52 +0200, Mario Torre ha scritto:
> Il giorno mer, 16/06/2010 alle 09.37 -0700, Phil Race ha scritto:
> > 6961732: FontMetrics.getLeading() may be negative in freetype-based 
> > OpenJDK builds
> > 
> > -phil.
> > 

Hi Phil,

I need to fill the reviewer field, what is your nickname id for OpenJDK?

Thanks,
Mario
-- 
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas GmbH, Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards: http://endsoftpatents.org/



From neugens at limasoftware.net  Wed Jun 16 18:49:14 2010
From: neugens at limasoftware.net (Mario Torre)
Date: Wed, 16 Jun 2010 20:49:14 +0200
Subject: [OpenJDK 2D-Dev] Font rendering issue
In-Reply-To: <1276710053.30565.1.camel@galactica>
References: <1269296837.2362.29.camel@localhost>
	<1269358114.2372.37.camel@localhost> <4BA91737.2070609@sun.com>
	<1269373906.2613.46.camel@moonlight> <4BA92049.7050002@sun.com>
	<1273097924.13679.188.camel@localhost>
	<1273400051.16277.47.camel@localhost>
	<1273407425.12737.84.camel@localhost>
	<1274126559.2392.41.camel@galactica>
	<1274209661.6830.16.camel@moonlight>
	<1274218414.2369.33.camel@galactica>
	<1274218778.2369.38.camel@galactica>
	<4BF325E8.6080301@oracle.com> <1274257734.1895.8.camel@moonlight>
	<4BF4594B.8070400@oracle.com> <1275061589.5908.19.camel@galactica>
	<1275066691.1781.1.camel@moonlight> <1275070336.2300.6.camel@galactica>
	<4C11590E.7040308@oracle.com> <1276242692.2438.13.camel@galactica>
	<1276703037.4279.37.camel@galactica>  <4C18FDDA.9010708@oracle.com>
	<1276707169.4279.50.camel@galactica>
	<1276710053.30565.1.camel@galactica>
Message-ID: <1276714154.30565.6.camel@galactica>

Il giorno mer, 16/06/2010 alle 19.40 +0200, Mario Torre ha scritto:
> Il giorno mer, 16/06/2010 alle 18.52 +0200, Mario Torre ha scritto:
> > Il giorno mer, 16/06/2010 alle 09.37 -0700, Phil Race ha scritto:
> > > 6961732: FontMetrics.getLeading() may be negative in freetype-based 
> > > OpenJDK builds
> > > 
> > > -phil.
> > > 

Hi Phil!

Just committed:

changeset:   2429:8b55669c7b7a
tag:         tip
user:        neugens
date:        Wed Jun 16 20:46:10 2010 +0200
files:       src/share/native/sun/font/freetypeScaler.c
description:
6961732: FontMetrics.getLeading() may be negative in freetype-based
OpenJDK builds.
Summary: Fix premature integer roundings to preserve correct height,
width and descent values for fonts
Reviewed-by: prr

Thanks for the support!

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/



From neugens.limasoftware at gmail.com  Wed Jun 16 18:45:36 2010
From: neugens.limasoftware at gmail.com (neugens.limasoftware at gmail.com)
Date: Wed, 16 Jun 2010 18:45:36 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6961732: FontMetrics.getLeading()
	may be negative in	freetype-based OpenJDK builds.
Message-ID: <20100616184556.C3D33472CA@hg.openjdk.java.net>

Changeset: 8b55669c7b7a
Author:    neugens
Date:      2010-06-16 20:46 +0200
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8b55669c7b7a

6961732: FontMetrics.getLeading() may be negative in freetype-based OpenJDK builds.
Summary: Fix premature integer roundings to preserve correct height, width and descent values for fonts
Reviewed-by: prr

! src/share/native/sun/font/freetypeScaler.c



From dlila at redhat.com  Wed Jun 16 20:17:54 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 16 Jun 2010 16:17:54 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] Fix for bug where long
 dashed lines can make graphics go black.
In-Reply-To: <1944502691.296831276719452585.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1591506393.296881276719474271.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

The reproducer is: https://bugzilla.redhat.com/attachment.cgi?id=417597

I have attached a JTreg test version of it.

----- Original Message -----
From: "Andrew John Hughes" <ahughes at redhat.com>
To: "Denis Lila" <dlila at redhat.com>
Cc: 2d-dev at openjdk.java.net
Sent: Wednesday, June 16, 2010 11:18:42 AM GMT -05:00 US/Canada Eastern
Subject: [PATCH FOR REVIEW] Fix for bug where long dashed lines can make  graphics go black.

On 9 June 2010 23:49, Denis Lila <dlila at redhat.com> wrote:
> Hello.
>
> I think I have a fix for this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=597227
>
> The bug was caused by a few integer overflows in sun/java2d/pisces/Dasher.java
> and sun/java2d/pisces/Stroker.java which would cause the whole container to
> fill up with whatever colour the line had. Dasher.java was prone to 2 overflows:
> one when computing the x and y coordinate lengths of the line at hand, and
> another which actually happened in PiscesMath.hypot(int,int). I fixed these
> two by turning the variables into longs and using PiscesMath.hypot(long,long).
>
> Stroker.java was only prone to overflows when drawing end caps or when adding
> offsets to points. I fixed these by making sure lineTo and moveTo never moved
> too close to the boundaries set by Integer.MAX_VALUE and Integer.MIN_VALUE.
>
> I welcome any feedback.
>
> Thank you,
> Denis Lila.

Webrev against 2d: http://cr.openjdk.java.net/~andrew/rh597227/

Do you have a reproducer for this?  It would help if that was included
as a JTreg test.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DrawLine.java
Type: text/x-java
Size: 1650 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100616/c487514d/DrawLine.java>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100616/c487514d/DrawLine.html>

From dlila at redhat.com  Wed Jun 16 20:28:27 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 16 Jun 2010 16:28:27 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length
In-Reply-To: <777806659.297731276720083927.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1806294284.297751276720107406.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

So, I've been looking at this a bit more, and I noticed that there
was a problem when a non-diagonal affine transformation was in effect.
This was because scaledLineWidth2 was being used to draw the end caps,
but this variable is valid only when the linear transformation
in effect is of the form [[n, 0], [0, n]].

I also simplified, somewhat, the drawing of round end caps.

Denis.

----- Original Message -----
From: "Denis Lila" <dlila at redhat.com>
To: "Jon VanAlten" <jon.vanalten at redhat.com>
Cc: 2d-dev at openjdk.java.net
Sent: Monday, June 14, 2010 5:04:46 PM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length

I can see one slight problem with this.
moveTo will check whether "if (prev == LINE_TO) {" in line 488.
This should be changed to "if (prev == LINE_TO || atLeastOneLine) {".
If this is not done, and if there are many moveTo's, each followed by
a lineTo to a line of 0 length, no end caps will be drawn for any of
the lines except perhaps the last lineTo.

See bug 197: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197
for reproducers, effects, and some more discussion on this.

Regards,
Denis Lila.

----- Original Message -----
From: "jon vanalten" <jon.vanalten at redhat.com>
To: 2d-dev at openjdk.java.net
Sent: Tuesday, June 8, 2010 10:10:21 AM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length

<BUMP>

Hi, I sent this a while ago.  Wondering if anyone has any feedback?

thanks in advance,

jon



----- "jon vanalten" <jon.vanalten at redhat.com> wrote:

> Hi,
> 
> I am new to this list, hopefully it is okay that I post a potential
> fix to a very minor rendering bug.
> 
> I've been looking at a bug reported downstream at IcedTea:
> 
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=383
> 
> To summarize, if a line is drawn via Graphics2D.drawLine() of zero
> length but thickness greater than 1, the endcap decorations are not
> rendered.  This is because the sun.java2d.pisces.Stroker class ignores
> such line segments.  This is ideal in most situations drawing complex
> shapes, but when such a line segment is the entire shape the end
> result nothing at all is rendered.  The closed-source Sun JDK
> implementation does render endcap decorations in this case, and the
> documentation of the BasicStroke class related to this suggests that
> they should be rendered.
> 
> I've put together a (possibly straw-man) fix.  Please do pick it
> apart, I have never looked at the graphics implementation before
> trying to tackle this bug.  I basically add a boolean to indicate that
> the finish() step should be taken if *any* lineTo() call has occurred,
> and in the finish() step detect if there are any segments and if no
> manually draw in the caps (while allowing normal behaviour in other
> cases).
> 
> See webrev at:
> 
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev/
> (or download)
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev.zip
> 
> Your comments are appreciated.
> 
> cheers,
> 
> jon


From dlila at redhat.com  Wed Jun 16 20:38:53 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 16 Jun 2010 16:38:53 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length
In-Reply-To: <1501323513.298951276720730456.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <617581156.298981276720733177.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Oops, I forgot to attach the patch.

----- Original Message -----
From: "Denis Lila" <dlila at redhat.com>
To: "Jon VanAlten" <jon.vanalten at redhat.com>
Cc: 2d-dev at openjdk.java.net
Sent: Wednesday, June 16, 2010 4:28:27 PM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length

So, I've been looking at this a bit more, and I noticed that there
was a problem when a non-diagonal affine transformation was in effect.
This was because scaledLineWidth2 was being used to draw the end caps,
but this variable is valid only when the linear transformation
in effect is of the form [[n, 0], [0, n]].

I also simplified, somewhat, the drawing of round end caps.

Denis.

----- Original Message -----
From: "Denis Lila" <dlila at redhat.com>
To: "Jon VanAlten" <jon.vanalten at redhat.com>
Cc: 2d-dev at openjdk.java.net
Sent: Monday, June 14, 2010 5:04:46 PM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length

I can see one slight problem with this.
moveTo will check whether "if (prev == LINE_TO) {" in line 488.
This should be changed to "if (prev == LINE_TO || atLeastOneLine) {".
If this is not done, and if there are many moveTo's, each followed by
a lineTo to a line of 0 length, no end caps will be drawn for any of
the lines except perhaps the last lineTo.

See bug 197: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197
for reproducers, effects, and some more discussion on this.

Regards,
Denis Lila.

----- Original Message -----
From: "jon vanalten" <jon.vanalten at redhat.com>
To: 2d-dev at openjdk.java.net
Sent: Tuesday, June 8, 2010 10:10:21 AM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Corner case drawing wide lines of zero length

<BUMP>

Hi, I sent this a while ago.  Wondering if anyone has any feedback?

thanks in advance,

jon



----- "jon vanalten" <jon.vanalten at redhat.com> wrote:

> Hi,
> 
> I am new to this list, hopefully it is okay that I post a potential
> fix to a very minor rendering bug.
> 
> I've been looking at a bug reported downstream at IcedTea:
> 
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=383
> 
> To summarize, if a line is drawn via Graphics2D.drawLine() of zero
> length but thickness greater than 1, the endcap decorations are not
> rendered.  This is because the sun.java2d.pisces.Stroker class ignores
> such line segments.  This is ideal in most situations drawing complex
> shapes, but when such a line segment is the entire shape the end
> result nothing at all is rendered.  The closed-source Sun JDK
> implementation does render endcap decorations in this case, and the
> documentation of the BasicStroke class related to this suggests that
> they should be rendered.
> 
> I've put together a (possibly straw-man) fix.  Please do pick it
> apart, I have never looked at the graphics implementation before
> trying to tackle this bug.  I basically add a boolean to indicate that
> the finish() step should be taken if *any* lineTo() call has occurred,
> and in the finish() step detect if there are any segments and if no
> manually draw in the caps (while allowing normal behaviour in other
> cases).
> 
> See webrev at:
> 
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev/
> (or download)
> http://icedtea.classpath.org/~vanaltj/webrevs/2d/zeroline/webrev.zip
> 
> Your comments are appreciated.
> 
> cheers,
> 
> jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0lenLineNoEndcaps.patch
Type: text/x-patch
Size: 4903 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100616/9befffd4/0lenLineNoEndcaps.patch>

From dlila at redhat.com  Thu Jun 17 20:17:31 2010
From: dlila at redhat.com (Denis Lila)
Date: Thu, 17 Jun 2010 16:17:31 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <517615560.398651276805532621.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1345697795.399041276805851845.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

So, I have been thinking about this, and I can't see a good
way to do it that wouldn't involve heavy changes to Pisces.

In order for Stroker to generate Bezier quarter circles, it would
have to implement a curveTo method, which means Stroker should 
start implementing PathConsumer2D and instead of using a LineSink
output it would have to use a PathConsumer2D output (either that, or
LineSink should include a curveTo method, but then there won't really
be any difference between a LineSink and a PathConsumer2D. By the way,
LineSink doesn't have any implemented methods, so why is it an abstract
class as opposed to an interface?)

Stroker is used in 3 ways:
1. As an implementation of BasicStroke's createStrokedShape method. This
uses a Path2D object as output.
2. As a way of feeding a PathConsumer2D without calling createStrokedShape
to generate an intermediate Shape. This uses a PathConsumer2D output.
3. As a way of feeding lines to a Renderer object, which generates alpha
tiles used for anti-aliasing that are fed to a cache and extracted as needed
by an AATileGenerator. Obviously, Stroker's output here is a Renderer.

1 and 2 aren't problems, because the underlying output objects support
Bezier curves. 3, however, doesn't, and it seems like implementing a 
curveTo method for Renderer would be very difficult because the way it 
generates alpha tiles is by scanning the drawn edges with horizontal
scan lines, and for each scan line finding the x-intersections of the scan
lines and the edges. Then it determines the alpha values (I'm not too sure
how it does this).
In order to implement Bezier curves in Renderer, we would have to have
a quick way of computing, for each scan line, all its intersections with
however many Bezier curves are being drawn.

I haven't given much thought to how this could be done, as I am not very
familiar with Bezier curves, but it doesn't seem easy enough to justify
fixing such a small bug.

----- Original Message -----
From: "Jim Graham" <james.graham at oracle.com>
To: "Denis Lila" <dlila at redhat.com>
Cc: 2d-dev at openjdk.java.net
Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.

I don't understand - why do we generate sample points based on the size 
of the cap?  Why not generate a pair of bezier quarter-circles and let 
the rasterizer deal with sampling?

			...jim

Denis Lila wrote:
> Hello.
> 
> I think I have a fix for this bug:
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
> 
> Basically, the problem is that if there is a magnifying affine transformation set on the graphics object and one tries to draw a line with small thickness and round end caps, the end caps appear jagged. This is because the computation of the length of the array that contains the points on the "pen" with which the decoration is drawn does not take into account the size of the pen after the magnification of the affine transformation. So, for example, if the line length was set to 1, and the transformation was a scaling by 10, the resulting pen would have a diameter of 10, but only 3 pen points would be computed (pi*untransformedLineWidth), so the end cap looks like a triangle.
> 
> My fix computes an approximation of the circumference of the transformed pen (which is an ellipse) and uses that as the number of points on the pen. The approximation is crude, but it is simple, faster than alternatives (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can say from observations that it works fairly well.
> 
> There is also icing on the cake, in the form of slight improvements in performance when the scaling is a zooming out. Example: if the original line width was 100, but g2d.scale(0.1,0.1) was set, then the resulting line would have a width of 10, so only ~31 points are necessary for the decoration to look like a circle, but without this patch, about 314 points are computed (and a line is emitted to each one of them).
> 
> I appreciate any feedback.
> 
> Regards,
> Denis Lila.
> 


From philip.race at oracle.com  Fri Jun 18 18:04:00 2010
From: philip.race at oracle.com (philip.race at oracle.com)
Date: Fri, 18 Jun 2010 18:04:00 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6961633: gui applications cause a
	jvm crash on	windows
Message-ID: <20100618180424.E494B47390@hg.openjdk.java.net>

Changeset: 83c7768292d7
Author:    prr
Date:      2010-06-18 11:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/83c7768292d7

6961633: gui applications cause a jvm crash on windows
Reviewed-by: ceisserer, bae

! make/sun/pisces/Makefile
! src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine
+ src/solaris/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine



From dlila at redhat.com  Fri Jun 18 20:58:23 2010
From: dlila at redhat.com (Denis Lila)
Date: Fri, 18 Jun 2010 16:58:23 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Antialiased horizontal or vertical lines.
In-Reply-To: <250883316.475611276894691546.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <699181964.475631276894703930.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello.

I noticed that anti aliased horizontal and vertical lines are 
not drawn properly. I've described the results (with pictures)
here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=509

In the patch, I try shifting line coordinates by half a pixel as 
soon as they're passed into Renderer.java:lineTo, and it seems to
fix it.

However, this seems a bit too easy, so if anyone can think of any
ways in which this fix breaks something, please let me know.

Thank you,
Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 509fix.patch
Type: text/x-patch
Size: 647 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100618/6c8a0a73/509fix.patch>

From james.graham at oracle.com  Sat Jun 19 00:00:28 2010
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 18 Jun 2010 17:00:28 -0700
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Antialiased horizontal or
	vertical lines.
In-Reply-To: <699181964.475631276894703930.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <699181964.475631276894703930.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C1C089C.7090908@oracle.com>

The Ductus pipeline will do the same thing with STROKE_PURE.  It sounds 
like maybe the Pisces pipeline doesn't support STROKE_NORMALIZE yet?

			...jim

Denis Lila wrote:
> Hello.
> 
> I noticed that anti aliased horizontal and vertical lines are 
> not drawn properly. I've described the results (with pictures)
> here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=509
> 
> In the patch, I try shifting line coordinates by half a pixel as 
> soon as they're passed into Renderer.java:lineTo, and it seems to
> fix it.
> 
> However, this seems a bit too easy, so if anyone can think of any
> ways in which this fix breaks something, please let me know.
> 
> Thank you,
> Denis.
> 


From james.graham at oracle.com  Sat Jun 19 01:19:59 2010
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 18 Jun 2010 18:19:59 -0700
Subject: [OpenJDK 2D-Dev] Fix for uniformly scaled dashed lines.
In-Reply-To: <736740737.197661276635211142.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <736740737.197661276635211142.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C1C1B3F.8050707@oracle.com>

Hi Denis,

Here are my thoughts on it:

- Lines are affinely transformed into lines.  The slope may be different 
before and after the transform, but both have a single slope.

- The ratio of a line length to its transformed line length is a scale 
factor that depends solely on the angle of the line.  Thus, for 
determining dashing you can simply compute this scale factor once for a 
given line and then that single scale factor can be applied to every 
dash segment.

It appears that your setup code takes these factors into account, though 
I haven't done a grueling line by line analysis as to whether you got 
the math right.

One more optimization is that once you know the angle of the line then 
you have a factor for how the length of a segment of that line relates 
to its dx and dy.  Note that for horizontal and vertical lines one of 
those factors may be Infinity, but every line will have a non-zero and 
non-infinity factor for one of those two dimensions.

This means that you can calculate the dashing by simply looping along 
the major axis of the line and comparing either the dx, or the dy to 
scaled "lengths" that represent the lengths of the transformed dashes 
projected onto the major axis.

Finally, the other dx,dy can be computed from the dx,dy of the major 
axis with another scale.  I am pretty sure that this dx=>dy or dy=>dx 
scale factor might be zero, but it would never be infinite if you are 
calculating along the major axis of the transformed line, but I didn't 
write out a proof for it.

Taking both of these concepts into account - can that make the inner 
loop even simpler?

			...jim

Denis Lila wrote:
> Hello.
> 
> I think I have a fix for this bug: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=504
> 
> The problem is caused by the "symmetric" variable in pisces/Dasher.java.
> symmetric is set to (m00 == m11 && m10 == -m01), and never changed.
> 
> It is only used in one place (in lineTo) to simplify the computation of
> the length of the line before an affine transformation A was applied to it.
> 
> This is why it causes a problem:
> If A = [[a00, a01], [a10, a11]] and (x,y) is a point obtained by applying
> A to some other point (x',y'), then what we want is the length of the vector
> (x',y'), which is ||Ainv*(x,y)||. Ainv = (1/det(A)) * [[a11, -a01],[-a10, a00]],
> so, after some calculations, ||Ainv*(x,y)|| ends up being equal to
> sqrt(x^2*(a11^2 + a10^2) + y^2*(a00^2 + a01^2) - x*y*(a11*a01 + a00*a10)) * 1/|det(A)|.
> If symmetric==true, this simplifies to:
> sqrt((a11^2 + a01^2) * (x^2 + y^2)) * 1/|det(A)|, and
> |det(A)| = a11^2 + a01^2, so, the final answer is:
> sqrt((x^2 + y^2)) / sqrt(det(A)). Therefore the problem in Dasher.java
> is that it divides by det(A), not sqrt(det(A)).
> 
> My fix for this was to remove the "symmetric" special case. Another possible fix
> would have been to introduce an instance "sqrtldet" and set it to sqrt(det(A)),
> and divide by that instead of det(A). This didn't seem worth it, because the only
> benefit we gain by having the "symmetric" variable is to save 3 multiplications
> and 1 division per iteration of the while(true) loop, at the expense of making the 
> code more complex, harder to read, introducing more opportunity for bugs, and adding
> hundreds of operations of overhead (since PiscesMath.sqrt would have to be called to
> initialize sqrtldet).
> 
> To make up for this slight performance loss I have moved the code that computes
> the transformed dash vectors outside of the while loop, since they are constant
> and they only need to be computed once for any one line.
> Moreover, computing the constant dash vectors inside the loop causes
> them to not really be constant (since they're computed by dividing numbers that
> aren't constant). This can cause irregularities in dashes (see comment 14 in
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197).
> 
> I would very much appreciate any comments/suggestions.
> 
> Thank you,
> Denis Lila.
> 


From james.graham at oracle.com  Sat Jun 19 01:28:01 2010
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 18 Jun 2010 18:28:01 -0700
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <1345697795.399041276805851845.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1345697795.399041276805851845.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C1C1D21.5070207@oracle.com>

Sigh - that makes sense.  One issue is that the resulting paths it 
generates are much more "verbose" than they need to be.  This would 
generally mean that it takes far more storage than it would otherwise 
need - and it means that if the result needs to be transformed then it 
would take many more computations to transform each segment than the bezier.

So, perhaps it would be worth having it check the type of the output and 
do either a bezier or a bunch of lines depending on if it is a PC2D or a 
LineSink?

Also, it isn't really that difficult to for Renderer to include its own 
Cubic/Quadratic flattening code, but it might involve more calculations 
than the round-cap code since it would have to be written for arbitrary 
beziers whereas if you know it is a quarter circle then it is easier to 
know how far to subdivide...  :-(

			...jim

Denis Lila wrote:
> So, I have been thinking about this, and I can't see a good
> way to do it that wouldn't involve heavy changes to Pisces.
> 
> In order for Stroker to generate Bezier quarter circles, it would
> have to implement a curveTo method, which means Stroker should 
> start implementing PathConsumer2D and instead of using a LineSink
> output it would have to use a PathConsumer2D output (either that, or
> LineSink should include a curveTo method, but then there won't really
> be any difference between a LineSink and a PathConsumer2D. By the way,
> LineSink doesn't have any implemented methods, so why is it an abstract
> class as opposed to an interface?)
> 
> Stroker is used in 3 ways:
> 1. As an implementation of BasicStroke's createStrokedShape method. This
> uses a Path2D object as output.
> 2. As a way of feeding a PathConsumer2D without calling createStrokedShape
> to generate an intermediate Shape. This uses a PathConsumer2D output.
> 3. As a way of feeding lines to a Renderer object, which generates alpha
> tiles used for anti-aliasing that are fed to a cache and extracted as needed
> by an AATileGenerator. Obviously, Stroker's output here is a Renderer.
> 
> 1 and 2 aren't problems, because the underlying output objects support
> Bezier curves. 3, however, doesn't, and it seems like implementing a 
> curveTo method for Renderer would be very difficult because the way it 
> generates alpha tiles is by scanning the drawn edges with horizontal
> scan lines, and for each scan line finding the x-intersections of the scan
> lines and the edges. Then it determines the alpha values (I'm not too sure
> how it does this).
> In order to implement Bezier curves in Renderer, we would have to have
> a quick way of computing, for each scan line, all its intersections with
> however many Bezier curves are being drawn.
> 
> I haven't given much thought to how this could be done, as I am not very
> familiar with Bezier curves, but it doesn't seem easy enough to justify
> fixing such a small bug.
> 
> ----- Original Message -----
> From: "Jim Graham" <james.graham at oracle.com>
> To: "Denis Lila" <dlila at redhat.com>
> Cc: 2d-dev at openjdk.java.net
> Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
> 
> I don't understand - why do we generate sample points based on the size 
> of the cap?  Why not generate a pair of bezier quarter-circles and let 
> the rasterizer deal with sampling?
> 
> 			...jim
> 
> Denis Lila wrote:
>> Hello.
>>
>> I think I have a fix for this bug:
>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
>>
>> Basically, the problem is that if there is a magnifying affine transformation set on the graphics object and one tries to draw a line with small thickness and round end caps, the end caps appear jagged. This is because the computation of the length of the array that contains the points on the "pen" with which the decoration is drawn does not take into account the size of the pen after the magnification of the affine transformation. So, for example, if the line length was set to 1, and the transformation was a scaling by 10, the resulting pen would have a diameter of 10, but only 3 pen points would be computed (pi*untransformedLineWidth), so the end cap looks like a triangle.
>>
>> My fix computes an approximation of the circumference of the transformed pen (which is an ellipse) and uses that as the number of points on the pen. The approximation is crude, but it is simple, faster than alternatives (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can say from observations that it works fairly well.
>>
>> There is also icing on the cake, in the form of slight improvements in performance when the scaling is a zooming out. Example: if the original line width was 100, but g2d.scale(0.1,0.1) was set, then the resulting line would have a width of 10, so only ~31 points are necessary for the decoration to look like a circle, but without this patch, about 314 points are computed (and a line is emitted to each one of them).
>>
>> I appreciate any feedback.
>>
>> Regards,
>> Denis Lila.
>>


From dlila at redhat.com  Mon Jun 21 15:07:12 2010
From: dlila at redhat.com (Denis Lila)
Date: Mon, 21 Jun 2010 11:07:12 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for uniformly scaled dashed lines.
In-Reply-To: <99194420.542741277132747924.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1929937193.543071277132832005.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

Thank you for your reply. It seems my code did not fully take into
account your second point after all.
The dx's of the transformed dashes are di*newx/<x,y> (where
di is the untransformed dash length, newx is the transformed x 
coordinate, and <x,y> is the untransformed line length). Obviously,
newx/<x,y> is constant for all dash segments, so it can be computed
outside of the loop, but I was computing t=di/<x,y> inside the loop, 
and then t*newx also inside the loop.

I have fixed this and I included an improved version of the patch.

However, I do not understand the second part of your e-mail
("One more optimization ..."). I am not sure what you mean by
"major axis", how one would loop along it, and what the "inner loop"
is. There are no nested loops in this method.

Also, the computation of the dxi and dyi of the transformed dash segment
dash[i] involves just 1 multiplication and 1 bit shift (along with an
overhead of 2 divisions and 2 bit shifts).
The computation of the actual endpoint of the dashes (done in the while(true)
loop) most of the time involves just 2 additions.
I am not sure how this can be made any simpler.

Thank you,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> Hi Denis,
> 
> Here are my thoughts on it:
> 
> - Lines are affinely transformed into lines.  The slope may be
> different 
> before and after the transform, but both have a single slope.
> 
> - The ratio of a line length to its transformed line length is a scale
> 
> factor that depends solely on the angle of the line.  Thus, for 
> determining dashing you can simply compute this scale factor once for
> a 
> given line and then that single scale factor can be applied to every 
> dash segment.
> 
> It appears that your setup code takes these factors into account,
> though 
> I haven't done a grueling line by line analysis as to whether you got
> 
> the math right.
> 
> One more optimization is that once you know the angle of the line then
> 
> you have a factor for how the length of a segment of that line relates
> 
> to its dx and dy.  Note that for horizontal and vertical lines one of
> 
> those factors may be Infinity, but every line will have a non-zero and
> 
> non-infinity factor for one of those two dimensions.
> 
> This means that you can calculate the dashing by simply looping along
> 
> the major axis of the line and comparing either the dx, or the dy to 
> scaled "lengths" that represent the lengths of the transformed dashes
> 
> projected onto the major axis.
> 
> Finally, the other dx,dy can be computed from the dx,dy of the major 
> axis with another scale.  I am pretty sure that this dx=>dy or dy=>dx
> 
> scale factor might be zero, but it would never be infinite if you are
> 
> calculating along the major axis of the transformed line, but I didn't
> 
> write out a proof for it.
> 
> Taking both of these concepts into account - can that make the inner 
> loop even simpler?
> 
> 			...jim
> 
> Denis Lila wrote:
> > Hello.
> > 
> > I think I have a fix for this bug:
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=504
> > 
> > The problem is caused by the "symmetric" variable in
> pisces/Dasher.java.
> > symmetric is set to (m00 == m11 && m10 == -m01), and never changed.
> > 
> > It is only used in one place (in lineTo) to simplify the computation
> of
> > the length of the line before an affine transformation A was applied
> to it.
> > 
> > This is why it causes a problem:
> > If A = [[a00, a01], [a10, a11]] and (x,y) is a point obtained by
> applying
> > A to some other point (x',y'), then what we want is the length of
> the vector
> > (x',y'), which is ||Ainv*(x,y)||. Ainv = (1/det(A)) * [[a11,
> -a01],[-a10, a00]],
> > so, after some calculations, ||Ainv*(x,y)|| ends up being equal to
> > sqrt(x^2*(a11^2 + a10^2) + y^2*(a00^2 + a01^2) - x*y*(a11*a01 +
> a00*a10)) * 1/|det(A)|.
> > If symmetric==true, this simplifies to:
> > sqrt((a11^2 + a01^2) * (x^2 + y^2)) * 1/|det(A)|, and
> > |det(A)| = a11^2 + a01^2, so, the final answer is:
> > sqrt((x^2 + y^2)) / sqrt(det(A)). Therefore the problem in
> Dasher.java
> > is that it divides by det(A), not sqrt(det(A)).
> > 
> > My fix for this was to remove the "symmetric" special case. Another
> possible fix
> > would have been to introduce an instance "sqrtldet" and set it to
> sqrt(det(A)),
> > and divide by that instead of det(A). This didn't seem worth it,
> because the only
> > benefit we gain by having the "symmetric" variable is to save 3
> multiplications
> > and 1 division per iteration of the while(true) loop, at the expense
> of making the 
> > code more complex, harder to read, introducing more opportunity for
> bugs, and adding
> > hundreds of operations of overhead (since PiscesMath.sqrt would have
> to be called to
> > initialize sqrtldet).
> > 
> > To make up for this slight performance loss I have moved the code
> that computes
> > the transformed dash vectors outside of the while loop, since they
> are constant
> > and they only need to be computed once for any one line.
> > Moreover, computing the constant dash vectors inside the loop
> causes
> > them to not really be constant (since they're computed by dividing
> numbers that
> > aren't constant). This can cause irregularities in dashes (see
> comment 14 in
> > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197).
> > 
> > I would very much appreciate any comments/suggestions.
> > 
> > Thank you,
> > Denis Lila.
> >


From dlila at redhat.com  Mon Jun 21 15:12:29 2010
From: dlila at redhat.com (Denis Lila)
Date: Mon, 21 Jun 2010 11:12:29 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Antialiased horizontal or
	vertical lines.
In-Reply-To: <4C1C089C.7090908@oracle.com>
Message-ID: <1899521085.544851277133149925.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Pisces doesn't support any of the STROKE_CONTROL hints.

Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> The Ductus pipeline will do the same thing with STROKE_PURE.  It
> sounds 
> like maybe the Pisces pipeline doesn't support STROKE_NORMALIZE yet?
> 
> 			...jim
> 
> Denis Lila wrote:
> > Hello.
> > 
> > I noticed that anti aliased horizontal and vertical lines are 
> > not drawn properly. I've described the results (with pictures)
> > here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=509
> > 
> > In the patch, I try shifting line coordinates by half a pixel as 
> > soon as they're passed into Renderer.java:lineTo, and it seems to
> > fix it.
> > 
> > However, this seems a bit too easy, so if anyone can think of any
> > ways in which this fix breaks something, please let me know.
> > 
> > Thank you,
> > Denis.
> >


From dlila at redhat.com  Mon Jun 21 16:02:49 2010
From: dlila at redhat.com (Denis Lila)
Date: Mon, 21 Jun 2010 12:02:49 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <675838873.551021277136115168.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <970107995.551171277136169279.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

I thought about checking the output and changing the behaviour 
depending on whether the output is a PC2D or a LineSink, but I didn't
implement it because I thought the point was to get rid of the sampling
at this stage. However, if performance is the issue, then I guess I'll
start working on it.

Although, I wonder whether it is really worth it. I think most lines drawn
won't be wider than about 5 pixels, which means that the current way will
emit about 7 lines, so that's 14 coordinates. 2 bezier quarter circles will
require 12 coordinates. In terms of storage, there isn't much difference, and
for lines of width 4 or smaller the current method is more efficient.

I'm also guessing that it's harder for the rasterizer to deal with bezier
curves than with straight lines, so is it possible that replacing the 
3.14*lineWidth/2 lines generated by the current method with 2 bezier 
quarter circles isn't worth it (for small lineWidths)?

Thanks,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> Sigh - that makes sense.  One issue is that the resulting paths it 
> generates are much more "verbose" than they need to be.  This would 
> generally mean that it takes far more storage than it would otherwise
> 
> need - and it means that if the result needs to be transformed then it
> 
> would take many more computations to transform each segment than the
> bezier.
> 
> So, perhaps it would be worth having it check the type of the output
> and 
> do either a bezier or a bunch of lines depending on if it is a PC2D or
> a 
> LineSink?
> 
> Also, it isn't really that difficult to for Renderer to include its
> own 
> Cubic/Quadratic flattening code, but it might involve more
> calculations 
> than the round-cap code since it would have to be written for
> arbitrary 
> beziers whereas if you know it is a quarter circle then it is easier
> to 
> know how far to subdivide...  :-(
> 
> 			...jim
> 
> Denis Lila wrote:
> > So, I have been thinking about this, and I can't see a good
> > way to do it that wouldn't involve heavy changes to Pisces.
> > 
> > In order for Stroker to generate Bezier quarter circles, it would
> > have to implement a curveTo method, which means Stroker should 
> > start implementing PathConsumer2D and instead of using a LineSink
> > output it would have to use a PathConsumer2D output (either that,
> or
> > LineSink should include a curveTo method, but then there won't
> really
> > be any difference between a LineSink and a PathConsumer2D. By the
> way,
> > LineSink doesn't have any implemented methods, so why is it an
> abstract
> > class as opposed to an interface?)
> > 
> > Stroker is used in 3 ways:
> > 1. As an implementation of BasicStroke's createStrokedShape method.
> This
> > uses a Path2D object as output.
> > 2. As a way of feeding a PathConsumer2D without calling
> createStrokedShape
> > to generate an intermediate Shape. This uses a PathConsumer2D
> output.
> > 3. As a way of feeding lines to a Renderer object, which generates
> alpha
> > tiles used for anti-aliasing that are fed to a cache and extracted
> as needed
> > by an AATileGenerator. Obviously, Stroker's output here is a
> Renderer.
> > 
> > 1 and 2 aren't problems, because the underlying output objects
> support
> > Bezier curves. 3, however, doesn't, and it seems like implementing a
> 
> > curveTo method for Renderer would be very difficult because the way
> it 
> > generates alpha tiles is by scanning the drawn edges with
> horizontal
> > scan lines, and for each scan line finding the x-intersections of
> the scan
> > lines and the edges. Then it determines the alpha values (I'm not
> too sure
> > how it does this).
> > In order to implement Bezier curves in Renderer, we would have to
> have
> > a quick way of computing, for each scan line, all its intersections
> with
> > however many Bezier curves are being drawn.
> > 
> > I haven't given much thought to how this could be done, as I am not
> very
> > familiar with Bezier curves, but it doesn't seem easy enough to
> justify
> > fixing such a small bug.
> > 
> > ----- Original Message -----
> > From: "Jim Graham" <james.graham at oracle.com>
> > To: "Denis Lila" <dlila at redhat.com>
> > Cc: 2d-dev at openjdk.java.net
> > Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada
> Eastern
> > Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on
> scaled lines.
> > 
> > I don't understand - why do we generate sample points based on the
> size 
> > of the cap?  Why not generate a pair of bezier quarter-circles and
> let 
> > the rasterizer deal with sampling?
> > 
> > 			...jim
> > 
> > Denis Lila wrote:
> >> Hello.
> >>
> >> I think I have a fix for this bug:
> >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
> >>
> >> Basically, the problem is that if there is a magnifying affine
> transformation set on the graphics object and one tries to draw a line
> with small thickness and round end caps, the end caps appear jagged.
> This is because the computation of the length of the array that
> contains the points on the "pen" with which the decoration is drawn
> does not take into account the size of the pen after the magnification
> of the affine transformation. So, for example, if the line length was
> set to 1, and the transformation was a scaling by 10, the resulting
> pen would have a diameter of 10, but only 3 pen points would be
> computed (pi*untransformedLineWidth), so the end cap looks like a
> triangle.
> >>
> >> My fix computes an approximation of the circumference of the
> transformed pen (which is an ellipse) and uses that as the number of
> points on the pen. The approximation is crude, but it is simple,
> faster than alternatives
> (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can say
> from observations that it works fairly well.
> >>
> >> There is also icing on the cake, in the form of slight improvements
> in performance when the scaling is a zooming out. Example: if the
> original line width was 100, but g2d.scale(0.1,0.1) was set, then the
> resulting line would have a width of 10, so only ~31 points are
> necessary for the decoration to look like a circle, but without this
> patch, about 314 points are computed (and a line is emitted to each
> one of them).
> >>
> >> I appreciate any feedback.
> >>
> >> Regards,
> >> Denis Lila.
> >>


From dlila at redhat.com  Mon Jun 21 16:06:49 2010
From: dlila at redhat.com (Denis Lila)
Date: Mon, 21 Jun 2010 12:06:49 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for uniformly scaled dashed lines.
In-Reply-To: <630399283.551331277136240552.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <372518257.551621277136409686.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Oops, I forgot the attachment.
I'm sorry.

----- "Denis Lila" <dlila at redhat.com> wrote:

> Hello Jim.
> 
> Thank you for your reply. It seems my code did not fully take into
> account your second point after all.
> The dx's of the transformed dashes are di*newx/<x,y> (where
> di is the untransformed dash length, newx is the transformed x 
> coordinate, and <x,y> is the untransformed line length). Obviously,
> newx/<x,y> is constant for all dash segments, so it can be computed
> outside of the loop, but I was computing t=di/<x,y> inside the loop, 
> and then t*newx also inside the loop.
> 
> I have fixed this and I included an improved version of the patch.
> 
> However, I do not understand the second part of your e-mail
> ("One more optimization ..."). I am not sure what you mean by
> "major axis", how one would loop along it, and what the "inner loop"
> is. There are no nested loops in this method.
> 
> Also, the computation of the dxi and dyi of the transformed dash
> segment
> dash[i] involves just 1 multiplication and 1 bit shift (along with an
> overhead of 2 divisions and 2 bit shifts).
> The computation of the actual endpoint of the dashes (done in the
> while(true)
> loop) most of the time involves just 2 additions.
> I am not sure how this can be made any simpler.
> 
> Thank you,
> Denis.
> 
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
> 
> > Hi Denis,
> > 
> > Here are my thoughts on it:
> > 
> > - Lines are affinely transformed into lines.  The slope may be
> > different 
> > before and after the transform, but both have a single slope.
> > 
> > - The ratio of a line length to its transformed line length is a
> scale
> > 
> > factor that depends solely on the angle of the line.  Thus, for 
> > determining dashing you can simply compute this scale factor once
> for
> > a 
> > given line and then that single scale factor can be applied to every
> 
> > dash segment.
> > 
> > It appears that your setup code takes these factors into account,
> > though 
> > I haven't done a grueling line by line analysis as to whether you
> got
> > 
> > the math right.
> > 
> > One more optimization is that once you know the angle of the line
> then
> > 
> > you have a factor for how the length of a segment of that line
> relates
> > 
> > to its dx and dy.  Note that for horizontal and vertical lines one
> of
> > 
> > those factors may be Infinity, but every line will have a non-zero
> and
> > 
> > non-infinity factor for one of those two dimensions.
> > 
> > This means that you can calculate the dashing by simply looping
> along
> > 
> > the major axis of the line and comparing either the dx, or the dy to
> 
> > scaled "lengths" that represent the lengths of the transformed
> dashes
> > 
> > projected onto the major axis.
> > 
> > Finally, the other dx,dy can be computed from the dx,dy of the major
> 
> > axis with another scale.  I am pretty sure that this dx=>dy or
> dy=>dx
> > 
> > scale factor might be zero, but it would never be infinite if you
> are
> > 
> > calculating along the major axis of the transformed line, but I
> didn't
> > 
> > write out a proof for it.
> > 
> > Taking both of these concepts into account - can that make the inner
> 
> > loop even simpler?
> > 
> > 			...jim
> > 
> > Denis Lila wrote:
> > > Hello.
> > > 
> > > I think I have a fix for this bug:
> > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=504
> > > 
> > > The problem is caused by the "symmetric" variable in
> > pisces/Dasher.java.
> > > symmetric is set to (m00 == m11 && m10 == -m01), and never
> changed.
> > > 
> > > It is only used in one place (in lineTo) to simplify the
> computation
> > of
> > > the length of the line before an affine transformation A was
> applied
> > to it.
> > > 
> > > This is why it causes a problem:
> > > If A = [[a00, a01], [a10, a11]] and (x,y) is a point obtained by
> > applying
> > > A to some other point (x',y'), then what we want is the length of
> > the vector
> > > (x',y'), which is ||Ainv*(x,y)||. Ainv = (1/det(A)) * [[a11,
> > -a01],[-a10, a00]],
> > > so, after some calculations, ||Ainv*(x,y)|| ends up being equal
> to
> > > sqrt(x^2*(a11^2 + a10^2) + y^2*(a00^2 + a01^2) - x*y*(a11*a01 +
> > a00*a10)) * 1/|det(A)|.
> > > If symmetric==true, this simplifies to:
> > > sqrt((a11^2 + a01^2) * (x^2 + y^2)) * 1/|det(A)|, and
> > > |det(A)| = a11^2 + a01^2, so, the final answer is:
> > > sqrt((x^2 + y^2)) / sqrt(det(A)). Therefore the problem in
> > Dasher.java
> > > is that it divides by det(A), not sqrt(det(A)).
> > > 
> > > My fix for this was to remove the "symmetric" special case.
> Another
> > possible fix
> > > would have been to introduce an instance "sqrtldet" and set it to
> > sqrt(det(A)),
> > > and divide by that instead of det(A). This didn't seem worth it,
> > because the only
> > > benefit we gain by having the "symmetric" variable is to save 3
> > multiplications
> > > and 1 division per iteration of the while(true) loop, at the
> expense
> > of making the 
> > > code more complex, harder to read, introducing more opportunity
> for
> > bugs, and adding
> > > hundreds of operations of overhead (since PiscesMath.sqrt would
> have
> > to be called to
> > > initialize sqrtldet).
> > > 
> > > To make up for this slight performance loss I have moved the code
> > that computes
> > > the transformed dash vectors outside of the while loop, since
> they
> > are constant
> > > and they only need to be computed once for any one line.
> > > Moreover, computing the constant dash vectors inside the loop
> > causes
> > > them to not really be constant (since they're computed by
> dividing
> > numbers that
> > > aren't constant). This can cause irregularities in dashes (see
> > comment 14 in
> > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197).
> > > 
> > > I would very much appreciate any comments/suggestions.
> > > 
> > > Thank you,
> > > Denis Lila.
> > >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dasherPerformanceAndUnifScalingv2.patch
Type: text/x-patch
Size: 5410 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100621/a73952ae/dasherPerformanceAndUnifScalingv2.patch>

From james.graham at oracle.com  Mon Jun 21 19:55:39 2010
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 21 Jun 2010 12:55:39 -0700
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Antialiased horizontal or
	vertical lines.
In-Reply-To: <1899521085.544851277133149925.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1899521085.544851277133149925.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C1FC3BB.5060005@oracle.com>

The behavior you describe is a consequence of the rasterization rules of 
Java2D - coordinates are at the edges of pixels and BasicStroke 
describes an outline that straddles the path with half of the line width 
on either side.  Thus, an integer horizontal or vertical line will be 
half on one row or column of pixels and half on another.

In other words, the rasterization rules require us to split AA lines 
into a double-wide half-opacity rasterization.

The solution for this was to introduce the STROKE_CONTROL hint which 
gives permission to slightly tweak the lines.  When it is set to 
STROKE_PURE then no tweaking is allowed or done and the production JDK 
pipelines will all produce the same result.  But, STROKE_NORMALIZE 
allows us to shift lines by up to half a pixel to avoid the problem.  We 
do this by default.

Note that the implementation does not simply add half a pixel to all 
coordinates - it rounds them to the nearest pixel center in all cases. 
Your solution will only solidify lines that are on integer coordinates.

Also, only strokes are so normalized - fills are left untouched.

So, in short, your solution to simply add half a pixel to the stroke 
coordinates to fix this problem doesn't work with STROKE_PURE and 
doesn't fully solve the STROKE_NORMALIZE case, which attempts to 
increase the solidity of every line regardless of pixel alignment...

			...jim

Denis Lila wrote:
> Pisces doesn't support any of the STROKE_CONTROL hints.
> 
> Denis.
> 
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
> 
>> The Ductus pipeline will do the same thing with STROKE_PURE.  It
>> sounds 
>> like maybe the Pisces pipeline doesn't support STROKE_NORMALIZE yet?
>>
>> 			...jim
>>
>> Denis Lila wrote:
>>> Hello.
>>>
>>> I noticed that anti aliased horizontal and vertical lines are 
>>> not drawn properly. I've described the results (with pictures)
>>> here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=509
>>>
>>> In the patch, I try shifting line coordinates by half a pixel as 
>>> soon as they're passed into Renderer.java:lineTo, and it seems to
>>> fix it.
>>>
>>> However, this seems a bit too easy, so if anyone can think of any
>>> ways in which this fix breaks something, please let me know.
>>>
>>> Thank you,
>>> Denis.
>>>


From james.graham at oracle.com  Mon Jun 21 20:00:29 2010
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 21 Jun 2010 13:00:29 -0700
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <970107995.551171277136169279.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <970107995.551171277136169279.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C1FC4DD.7090408@oracle.com>

Hi Denis,

Consider the case of using BasicStroke.createStrokedShape().  How do you 
know how many pixels the resulting path will occupy?  You can't reduce 
to concrete samples if you don't know the transform.

So, for rendering, then you may be correct.  But for cases where the 
path is being asked for then beziers are the only responsible solution...

			...jim

Denis Lila wrote:
> Hello Jim.
> 
> I thought about checking the output and changing the behaviour 
> depending on whether the output is a PC2D or a LineSink, but I didn't
> implement it because I thought the point was to get rid of the sampling
> at this stage. However, if performance is the issue, then I guess I'll
> start working on it.
> 
> Although, I wonder whether it is really worth it. I think most lines drawn
> won't be wider than about 5 pixels, which means that the current way will
> emit about 7 lines, so that's 14 coordinates. 2 bezier quarter circles will
> require 12 coordinates. In terms of storage, there isn't much difference, and
> for lines of width 4 or smaller the current method is more efficient.
> 
> I'm also guessing that it's harder for the rasterizer to deal with bezier
> curves than with straight lines, so is it possible that replacing the 
> 3.14*lineWidth/2 lines generated by the current method with 2 bezier 
> quarter circles isn't worth it (for small lineWidths)?
> 
> Thanks,
> Denis.
> 
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
> 
>> Sigh - that makes sense.  One issue is that the resulting paths it 
>> generates are much more "verbose" than they need to be.  This would 
>> generally mean that it takes far more storage than it would otherwise
>>
>> need - and it means that if the result needs to be transformed then it
>>
>> would take many more computations to transform each segment than the
>> bezier.
>>
>> So, perhaps it would be worth having it check the type of the output
>> and 
>> do either a bezier or a bunch of lines depending on if it is a PC2D or
>> a 
>> LineSink?
>>
>> Also, it isn't really that difficult to for Renderer to include its
>> own 
>> Cubic/Quadratic flattening code, but it might involve more
>> calculations 
>> than the round-cap code since it would have to be written for
>> arbitrary 
>> beziers whereas if you know it is a quarter circle then it is easier
>> to 
>> know how far to subdivide...  :-(
>>
>> 			...jim
>>
>> Denis Lila wrote:
>>> So, I have been thinking about this, and I can't see a good
>>> way to do it that wouldn't involve heavy changes to Pisces.
>>>
>>> In order for Stroker to generate Bezier quarter circles, it would
>>> have to implement a curveTo method, which means Stroker should 
>>> start implementing PathConsumer2D and instead of using a LineSink
>>> output it would have to use a PathConsumer2D output (either that,
>> or
>>> LineSink should include a curveTo method, but then there won't
>> really
>>> be any difference between a LineSink and a PathConsumer2D. By the
>> way,
>>> LineSink doesn't have any implemented methods, so why is it an
>> abstract
>>> class as opposed to an interface?)
>>>
>>> Stroker is used in 3 ways:
>>> 1. As an implementation of BasicStroke's createStrokedShape method.
>> This
>>> uses a Path2D object as output.
>>> 2. As a way of feeding a PathConsumer2D without calling
>> createStrokedShape
>>> to generate an intermediate Shape. This uses a PathConsumer2D
>> output.
>>> 3. As a way of feeding lines to a Renderer object, which generates
>> alpha
>>> tiles used for anti-aliasing that are fed to a cache and extracted
>> as needed
>>> by an AATileGenerator. Obviously, Stroker's output here is a
>> Renderer.
>>> 1 and 2 aren't problems, because the underlying output objects
>> support
>>> Bezier curves. 3, however, doesn't, and it seems like implementing a
>>> curveTo method for Renderer would be very difficult because the way
>> it 
>>> generates alpha tiles is by scanning the drawn edges with
>> horizontal
>>> scan lines, and for each scan line finding the x-intersections of
>> the scan
>>> lines and the edges. Then it determines the alpha values (I'm not
>> too sure
>>> how it does this).
>>> In order to implement Bezier curves in Renderer, we would have to
>> have
>>> a quick way of computing, for each scan line, all its intersections
>> with
>>> however many Bezier curves are being drawn.
>>>
>>> I haven't given much thought to how this could be done, as I am not
>> very
>>> familiar with Bezier curves, but it doesn't seem easy enough to
>> justify
>>> fixing such a small bug.
>>>
>>> ----- Original Message -----
>>> From: "Jim Graham" <james.graham at oracle.com>
>>> To: "Denis Lila" <dlila at redhat.com>
>>> Cc: 2d-dev at openjdk.java.net
>>> Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada
>> Eastern
>>> Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on
>> scaled lines.
>>> I don't understand - why do we generate sample points based on the
>> size 
>>> of the cap?  Why not generate a pair of bezier quarter-circles and
>> let 
>>> the rasterizer deal with sampling?
>>>
>>> 			...jim
>>>
>>> Denis Lila wrote:
>>>> Hello.
>>>>
>>>> I think I have a fix for this bug:
>>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
>>>>
>>>> Basically, the problem is that if there is a magnifying affine
>> transformation set on the graphics object and one tries to draw a line
>> with small thickness and round end caps, the end caps appear jagged.
>> This is because the computation of the length of the array that
>> contains the points on the "pen" with which the decoration is drawn
>> does not take into account the size of the pen after the magnification
>> of the affine transformation. So, for example, if the line length was
>> set to 1, and the transformation was a scaling by 10, the resulting
>> pen would have a diameter of 10, but only 3 pen points would be
>> computed (pi*untransformedLineWidth), so the end cap looks like a
>> triangle.
>>>> My fix computes an approximation of the circumference of the
>> transformed pen (which is an ellipse) and uses that as the number of
>> points on the pen. The approximation is crude, but it is simple,
>> faster than alternatives
>> (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can say
>> from observations that it works fairly well.
>>>> There is also icing on the cake, in the form of slight improvements
>> in performance when the scaling is a zooming out. Example: if the
>> original line width was 100, but g2d.scale(0.1,0.1) was set, then the
>> resulting line would have a width of 10, so only ~31 points are
>> necessary for the decoration to look like a circle, but without this
>> patch, about 314 points are computed (and a line is emitted to each
>> one of them).
>>>> I appreciate any feedback.
>>>>
>>>> Regards,
>>>> Denis Lila.
>>>>


From james.graham at oracle.com  Mon Jun 21 20:30:21 2010
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 21 Jun 2010 13:30:21 -0700
Subject: [OpenJDK 2D-Dev] Fix for uniformly scaled dashed lines.
In-Reply-To: <1929937193.543071277132832005.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1929937193.543071277132832005.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C1FCBDD.7060005@oracle.com>

Hi Denis,

One request on your code - please don't use the variable "lowercase L". 
  On my screen with Courier font I cannot distinguish between the number 
1 and the lowercase L character and so I cannot verify if your code is 
correct.

Also, by "inner loop" I meant the single loop.  I use the term to mean 
the "loop that does all the work at the innermost level" without regard 
to whether the case contains only 1 loop and is therefore a degenerate 
application of the term.

My comment about the "major axis" stuff was an optimization that is no 
longer needed.  I though I saw calls to hypot() in the inner loop, but I 
just noticed that those were in deleted code and the new code has no 
such calls, so you can ignore it.  If it makes the comment clearer, 
"major axis" is either the X or Y axis depending on whether the line is 
more horizontal or vertical, but you can ignore it now.

I will note that the 2 arrays you compute are simply scaled versions of 
the dash array and so we could eliminate the extra allocations by simply 
computing the values inside the loop at the cost of a multiply per dash 
segment to offset the cost of an allocation per incoming line segment. 
Also, you would no longer need to compute the "dashesToCompute" value 
and the setup code would be much, much simpler (basically you just need 
to compute the untransformed length and the cx and cy values and then 
jump into the loop).

I'm leaning towards the multiplies in the loop to greatly simplify the 
code...

(One last comment - have you checked what happens with the code in the 
presence of a degenerate transform?  A non-invertible transform may run 
the risk of an infinite loop if you assume that you can reverse compute 
the line length and end up with a finite value...)

			...jim

Denis Lila wrote:
> Hello Jim.
> 
> Thank you for your reply. It seems my code did not fully take into
> account your second point after all.
> The dx's of the transformed dashes are di*newx/<x,y> (where
> di is the untransformed dash length, newx is the transformed x 
> coordinate, and <x,y> is the untransformed line length). Obviously,
> newx/<x,y> is constant for all dash segments, so it can be computed
> outside of the loop, but I was computing t=di/<x,y> inside the loop, 
> and then t*newx also inside the loop.
> 
> I have fixed this and I included an improved version of the patch.
> 
> However, I do not understand the second part of your e-mail
> ("One more optimization ..."). I am not sure what you mean by
> "major axis", how one would loop along it, and what the "inner loop"
> is. There are no nested loops in this method.
> 
> Also, the computation of the dxi and dyi of the transformed dash segment
> dash[i] involves just 1 multiplication and 1 bit shift (along with an
> overhead of 2 divisions and 2 bit shifts).
> The computation of the actual endpoint of the dashes (done in the while(true)
> loop) most of the time involves just 2 additions.
> I am not sure how this can be made any simpler.
> 
> Thank you,
> Denis.
> 
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
> 
>> Hi Denis,
>>
>> Here are my thoughts on it:
>>
>> - Lines are affinely transformed into lines.  The slope may be
>> different 
>> before and after the transform, but both have a single slope.
>>
>> - The ratio of a line length to its transformed line length is a scale
>>
>> factor that depends solely on the angle of the line.  Thus, for 
>> determining dashing you can simply compute this scale factor once for
>> a 
>> given line and then that single scale factor can be applied to every 
>> dash segment.
>>
>> It appears that your setup code takes these factors into account,
>> though 
>> I haven't done a grueling line by line analysis as to whether you got
>>
>> the math right.
>>
>> One more optimization is that once you know the angle of the line then
>>
>> you have a factor for how the length of a segment of that line relates
>>
>> to its dx and dy.  Note that for horizontal and vertical lines one of
>>
>> those factors may be Infinity, but every line will have a non-zero and
>>
>> non-infinity factor for one of those two dimensions.
>>
>> This means that you can calculate the dashing by simply looping along
>>
>> the major axis of the line and comparing either the dx, or the dy to 
>> scaled "lengths" that represent the lengths of the transformed dashes
>>
>> projected onto the major axis.
>>
>> Finally, the other dx,dy can be computed from the dx,dy of the major 
>> axis with another scale.  I am pretty sure that this dx=>dy or dy=>dx
>>
>> scale factor might be zero, but it would never be infinite if you are
>>
>> calculating along the major axis of the transformed line, but I didn't
>>
>> write out a proof for it.
>>
>> Taking both of these concepts into account - can that make the inner 
>> loop even simpler?
>>
>> 			...jim
>>
>> Denis Lila wrote:
>>> Hello.
>>>
>>> I think I have a fix for this bug:
>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=504
>>> The problem is caused by the "symmetric" variable in
>> pisces/Dasher.java.
>>> symmetric is set to (m00 == m11 && m10 == -m01), and never changed.
>>>
>>> It is only used in one place (in lineTo) to simplify the computation
>> of
>>> the length of the line before an affine transformation A was applied
>> to it.
>>> This is why it causes a problem:
>>> If A = [[a00, a01], [a10, a11]] and (x,y) is a point obtained by
>> applying
>>> A to some other point (x',y'), then what we want is the length of
>> the vector
>>> (x',y'), which is ||Ainv*(x,y)||. Ainv = (1/det(A)) * [[a11,
>> -a01],[-a10, a00]],
>>> so, after some calculations, ||Ainv*(x,y)|| ends up being equal to
>>> sqrt(x^2*(a11^2 + a10^2) + y^2*(a00^2 + a01^2) - x*y*(a11*a01 +
>> a00*a10)) * 1/|det(A)|.
>>> If symmetric==true, this simplifies to:
>>> sqrt((a11^2 + a01^2) * (x^2 + y^2)) * 1/|det(A)|, and
>>> |det(A)| = a11^2 + a01^2, so, the final answer is:
>>> sqrt((x^2 + y^2)) / sqrt(det(A)). Therefore the problem in
>> Dasher.java
>>> is that it divides by det(A), not sqrt(det(A)).
>>>
>>> My fix for this was to remove the "symmetric" special case. Another
>> possible fix
>>> would have been to introduce an instance "sqrtldet" and set it to
>> sqrt(det(A)),
>>> and divide by that instead of det(A). This didn't seem worth it,
>> because the only
>>> benefit we gain by having the "symmetric" variable is to save 3
>> multiplications
>>> and 1 division per iteration of the while(true) loop, at the expense
>> of making the 
>>> code more complex, harder to read, introducing more opportunity for
>> bugs, and adding
>>> hundreds of operations of overhead (since PiscesMath.sqrt would have
>> to be called to
>>> initialize sqrtldet).
>>>
>>> To make up for this slight performance loss I have moved the code
>> that computes
>>> the transformed dash vectors outside of the while loop, since they
>> are constant
>>> and they only need to be computed once for any one line.
>>> Moreover, computing the constant dash vectors inside the loop
>> causes
>>> them to not really be constant (since they're computed by dividing
>> numbers that
>>> aren't constant). This can cause irregularities in dashes (see
>> comment 14 in
>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197).
>>>
>>> I would very much appreciate any comments/suggestions.
>>>
>>> Thank you,
>>> Denis Lila.
>>>


From dlila at redhat.com  Tue Jun 22 14:30:47 2010
From: dlila at redhat.com (Denis Lila)
Date: Tue, 22 Jun 2010 10:30:47 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for uniformly scaled dashed lines.
In-Reply-To: <178359837.626451277217029644.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1352155522.626481277217047436.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

Sorry about the l. It was already there, and I wanted to change as
little as possible.

As for whether to compute the transformed dashes inside the while(true)
or not... the main point of this patch was to fix a bug where zooming 
transforms weren't handled properly. The efficiency improvements were
just something I threw in because a bunch of stuff was being computed
too many times, so I can go either way. I should note that the allocations
can be easily removed by just turning the arrays into fields, and allocating
them at setParameters, since for any one Dasher object their length is 
constant. So the choice is between clearer and slower code and mine. I
have 2 patches ready, one for each way of doing it. Just tell me which
to send.

As for degenerate inputs: I did think about non-invertible transforms, but
since they weren't being handled in the original Dasher and Stroker, and
since the API provides no way of using non-invertible transforms (the only
possible ones are shear, rotate, translate, and scale, all of which are
invertible), I didn't think it was necessary to check for them.
How do you think they should be handled? I think we should just throw
an InvalidInputException if the determinant is 0.
One more thing: it turns out that by computing dashes outside of the while(true)
I introduced the possibility for divide by zero errors. I fixed this.

Thanks,
Denis.
----- "Jim Graham" <james.graham at oracle.com> wrote:

> Hi Denis,
> 
> One request on your code - please don't use the variable "lowercase
> L". 
>   On my screen with Courier font I cannot distinguish between the
> number 
> 1 and the lowercase L character and so I cannot verify if your code is
> 
> correct.
> 
> Also, by "inner loop" I meant the single loop.  I use the term to mean
> 
> the "loop that does all the work at the innermost level" without
> regard 
> to whether the case contains only 1 loop and is therefore a degenerate
> 
> application of the term.
> 
> My comment about the "major axis" stuff was an optimization that is no
> 
> longer needed.  I though I saw calls to hypot() in the inner loop, but
> I 
> just noticed that those were in deleted code and the new code has no 
> such calls, so you can ignore it.  If it makes the comment clearer, 
> "major axis" is either the X or Y axis depending on whether the line
> is 
> more horizontal or vertical, but you can ignore it now.
> 
> I will note that the 2 arrays you compute are simply scaled versions
> of 
> the dash array and so we could eliminate the extra allocations by
> simply 
> computing the values inside the loop at the cost of a multiply per
> dash 
> segment to offset the cost of an allocation per incoming line segment.
> 
> Also, you would no longer need to compute the "dashesToCompute" value
> 
> and the setup code would be much, much simpler (basically you just
> need 
> to compute the untransformed length and the cx and cy values and then
> 
> jump into the loop).
> 
> I'm leaning towards the multiplies in the loop to greatly simplify the
> 
> code...
> 
> (One last comment - have you checked what happens with the code in the
> 
> presence of a degenerate transform?  A non-invertible transform may
> run 
> the risk of an infinite loop if you assume that you can reverse
> compute 
> the line length and end up with a finite value...)
> 
> 			...jim
> 
> Denis Lila wrote:
> > Hello Jim.
> > 
> > Thank you for your reply. It seems my code did not fully take into
> > account your second point after all.
> > The dx's of the transformed dashes are di*newx/<x,y> (where
> > di is the untransformed dash length, newx is the transformed x 
> > coordinate, and <x,y> is the untransformed line length). Obviously,
> > newx/<x,y> is constant for all dash segments, so it can be computed
> > outside of the loop, but I was computing t=di/<x,y> inside the loop,
> 
> > and then t*newx also inside the loop.
> > 
> > I have fixed this and I included an improved version of the patch.
> > 
> > However, I do not understand the second part of your e-mail
> > ("One more optimization ..."). I am not sure what you mean by
> > "major axis", how one would loop along it, and what the "inner
> loop"
> > is. There are no nested loops in this method.
> > 
> > Also, the computation of the dxi and dyi of the transformed dash
> segment
> > dash[i] involves just 1 multiplication and 1 bit shift (along with
> an
> > overhead of 2 divisions and 2 bit shifts).
> > The computation of the actual endpoint of the dashes (done in the
> while(true)
> > loop) most of the time involves just 2 additions.
> > I am not sure how this can be made any simpler.
> > 
> > Thank you,
> > Denis.
> > 
> > ----- "Jim Graham" <james.graham at oracle.com> wrote:
> > 
> >> Hi Denis,
> >>
> >> Here are my thoughts on it:
> >>
> >> - Lines are affinely transformed into lines.  The slope may be
> >> different 
> >> before and after the transform, but both have a single slope.
> >>
> >> - The ratio of a line length to its transformed line length is a
> scale
> >>
> >> factor that depends solely on the angle of the line.  Thus, for 
> >> determining dashing you can simply compute this scale factor once
> for
> >> a 
> >> given line and then that single scale factor can be applied to
> every 
> >> dash segment.
> >>
> >> It appears that your setup code takes these factors into account,
> >> though 
> >> I haven't done a grueling line by line analysis as to whether you
> got
> >>
> >> the math right.
> >>
> >> One more optimization is that once you know the angle of the line
> then
> >>
> >> you have a factor for how the length of a segment of that line
> relates
> >>
> >> to its dx and dy.  Note that for horizontal and vertical lines one
> of
> >>
> >> those factors may be Infinity, but every line will have a non-zero
> and
> >>
> >> non-infinity factor for one of those two dimensions.
> >>
> >> This means that you can calculate the dashing by simply looping
> along
> >>
> >> the major axis of the line and comparing either the dx, or the dy
> to 
> >> scaled "lengths" that represent the lengths of the transformed
> dashes
> >>
> >> projected onto the major axis.
> >>
> >> Finally, the other dx,dy can be computed from the dx,dy of the
> major 
> >> axis with another scale.  I am pretty sure that this dx=>dy or
> dy=>dx
> >>
> >> scale factor might be zero, but it would never be infinite if you
> are
> >>
> >> calculating along the major axis of the transformed line, but I
> didn't
> >>
> >> write out a proof for it.
> >>
> >> Taking both of these concepts into account - can that make the
> inner 
> >> loop even simpler?
> >>
> >> 			...jim
> >>
> >> Denis Lila wrote:
> >>> Hello.
> >>>
> >>> I think I have a fix for this bug:
> >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=504
> >>> The problem is caused by the "symmetric" variable in
> >> pisces/Dasher.java.
> >>> symmetric is set to (m00 == m11 && m10 == -m01), and never
> changed.
> >>>
> >>> It is only used in one place (in lineTo) to simplify the
> computation
> >> of
> >>> the length of the line before an affine transformation A was
> applied
> >> to it.
> >>> This is why it causes a problem:
> >>> If A = [[a00, a01], [a10, a11]] and (x,y) is a point obtained by
> >> applying
> >>> A to some other point (x',y'), then what we want is the length of
> >> the vector
> >>> (x',y'), which is ||Ainv*(x,y)||. Ainv = (1/det(A)) * [[a11,
> >> -a01],[-a10, a00]],
> >>> so, after some calculations, ||Ainv*(x,y)|| ends up being equal
> to
> >>> sqrt(x^2*(a11^2 + a10^2) + y^2*(a00^2 + a01^2) - x*y*(a11*a01 +
> >> a00*a10)) * 1/|det(A)|.
> >>> If symmetric==true, this simplifies to:
> >>> sqrt((a11^2 + a01^2) * (x^2 + y^2)) * 1/|det(A)|, and
> >>> |det(A)| = a11^2 + a01^2, so, the final answer is:
> >>> sqrt((x^2 + y^2)) / sqrt(det(A)). Therefore the problem in
> >> Dasher.java
> >>> is that it divides by det(A), not sqrt(det(A)).
> >>>
> >>> My fix for this was to remove the "symmetric" special case.
> Another
> >> possible fix
> >>> would have been to introduce an instance "sqrtldet" and set it to
> >> sqrt(det(A)),
> >>> and divide by that instead of det(A). This didn't seem worth it,
> >> because the only
> >>> benefit we gain by having the "symmetric" variable is to save 3
> >> multiplications
> >>> and 1 division per iteration of the while(true) loop, at the
> expense
> >> of making the 
> >>> code more complex, harder to read, introducing more opportunity
> for
> >> bugs, and adding
> >>> hundreds of operations of overhead (since PiscesMath.sqrt would
> have
> >> to be called to
> >>> initialize sqrtldet).
> >>>
> >>> To make up for this slight performance loss I have moved the code
> >> that computes
> >>> the transformed dash vectors outside of the while loop, since
> they
> >> are constant
> >>> and they only need to be computed once for any one line.
> >>> Moreover, computing the constant dash vectors inside the loop
> >> causes
> >>> them to not really be constant (since they're computed by
> dividing
> >> numbers that
> >>> aren't constant). This can cause irregularities in dashes (see
> >> comment 14 in
> >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197).
> >>>
> >>> I would very much appreciate any comments/suggestions.
> >>>
> >>> Thank you,
> >>> Denis Lila.
> >>>


From dlila at redhat.com  Tue Jun 22 14:58:47 2010
From: dlila at redhat.com (Denis Lila)
Date: Tue, 22 Jun 2010 10:58:47 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <1161581964.628421277218251409.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <2015058373.629241277218727181.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

That's true.

Well, if we're worried about the generated paths being verbose
and taking long to process then the problem extends beyond just
drawing round end caps. As far as I can see, whenever a path is 
drawn that doesn't consist only of straight lines (i.e. an ellipse),
a flattening path iterator is being used to feed Stroker. So all
the bezier curves are still broken down into tiny straight lines,
just not by Stroker itself.

So, my question is, given a bezier curve C and a number w, is
there a way of quickly computing the control points of two bezier
curves C1, C2 such that the stuff between C1 and C2 is the widened
path?
More formally: compute the control points of C1, C2, where
C1 = {(x,y) + N(x,y)*(w/2)  | (x,y) in C}
C1 = {(x,y) - N(x,y)*(w/2)  | (x,y) in C}, where N(x,y) is the normal
of C at (x,y).

If we could do this easily, then we can just make a new class that
outputs bezier curves that is similar in purpose to Stroker, but that 
is used only when the output can handle bezier curves. This way, the
only use left for Stroker would be when anti-aliasing, and for
every thing else we wouldn't have to use a flattening path iterator.

Thanks,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> Hi Denis,
> 
> Consider the case of using BasicStroke.createStrokedShape().  How do
> you 
> know how many pixels the resulting path will occupy?  You can't reduce
> 
> to concrete samples if you don't know the transform.
> 
> So, for rendering, then you may be correct.  But for cases where the 
> path is being asked for then beziers are the only responsible
> solution...
> 
> 			...jim
> 
> Denis Lila wrote:
> > Hello Jim.
> > 
> > I thought about checking the output and changing the behaviour 
> > depending on whether the output is a PC2D or a LineSink, but I
> didn't
> > implement it because I thought the point was to get rid of the
> sampling
> > at this stage. However, if performance is the issue, then I guess
> I'll
> > start working on it.
> > 
> > Although, I wonder whether it is really worth it. I think most lines
> drawn
> > won't be wider than about 5 pixels, which means that the current way
> will
> > emit about 7 lines, so that's 14 coordinates. 2 bezier quarter
> circles will
> > require 12 coordinates. In terms of storage, there isn't much
> difference, and
> > for lines of width 4 or smaller the current method is more
> efficient.
> > 
> > I'm also guessing that it's harder for the rasterizer to deal with
> bezier
> > curves than with straight lines, so is it possible that replacing
> the 
> > 3.14*lineWidth/2 lines generated by the current method with 2 bezier
> 
> > quarter circles isn't worth it (for small lineWidths)?
> > 
> > Thanks,
> > Denis.
> > 
> > ----- "Jim Graham" <james.graham at oracle.com> wrote:
> > 
> >> Sigh - that makes sense.  One issue is that the resulting paths it
> 
> >> generates are much more "verbose" than they need to be.  This would
> 
> >> generally mean that it takes far more storage than it would
> otherwise
> >>
> >> need - and it means that if the result needs to be transformed then
> it
> >>
> >> would take many more computations to transform each segment than
> the
> >> bezier.
> >>
> >> So, perhaps it would be worth having it check the type of the
> output
> >> and 
> >> do either a bezier or a bunch of lines depending on if it is a PC2D
> or
> >> a 
> >> LineSink?
> >>
> >> Also, it isn't really that difficult to for Renderer to include
> its
> >> own 
> >> Cubic/Quadratic flattening code, but it might involve more
> >> calculations 
> >> than the round-cap code since it would have to be written for
> >> arbitrary 
> >> beziers whereas if you know it is a quarter circle then it is
> easier
> >> to 
> >> know how far to subdivide...  :-(
> >>
> >> 			...jim
> >>
> >> Denis Lila wrote:
> >>> So, I have been thinking about this, and I can't see a good
> >>> way to do it that wouldn't involve heavy changes to Pisces.
> >>>
> >>> In order for Stroker to generate Bezier quarter circles, it would
> >>> have to implement a curveTo method, which means Stroker should 
> >>> start implementing PathConsumer2D and instead of using a LineSink
> >>> output it would have to use a PathConsumer2D output (either that,
> >> or
> >>> LineSink should include a curveTo method, but then there won't
> >> really
> >>> be any difference between a LineSink and a PathConsumer2D. By the
> >> way,
> >>> LineSink doesn't have any implemented methods, so why is it an
> >> abstract
> >>> class as opposed to an interface?)
> >>>
> >>> Stroker is used in 3 ways:
> >>> 1. As an implementation of BasicStroke's createStrokedShape
> method.
> >> This
> >>> uses a Path2D object as output.
> >>> 2. As a way of feeding a PathConsumer2D without calling
> >> createStrokedShape
> >>> to generate an intermediate Shape. This uses a PathConsumer2D
> >> output.
> >>> 3. As a way of feeding lines to a Renderer object, which
> generates
> >> alpha
> >>> tiles used for anti-aliasing that are fed to a cache and
> extracted
> >> as needed
> >>> by an AATileGenerator. Obviously, Stroker's output here is a
> >> Renderer.
> >>> 1 and 2 aren't problems, because the underlying output objects
> >> support
> >>> Bezier curves. 3, however, doesn't, and it seems like implementing
> a
> >>> curveTo method for Renderer would be very difficult because the
> way
> >> it 
> >>> generates alpha tiles is by scanning the drawn edges with
> >> horizontal
> >>> scan lines, and for each scan line finding the x-intersections of
> >> the scan
> >>> lines and the edges. Then it determines the alpha values (I'm not
> >> too sure
> >>> how it does this).
> >>> In order to implement Bezier curves in Renderer, we would have to
> >> have
> >>> a quick way of computing, for each scan line, all its
> intersections
> >> with
> >>> however many Bezier curves are being drawn.
> >>>
> >>> I haven't given much thought to how this could be done, as I am
> not
> >> very
> >>> familiar with Bezier curves, but it doesn't seem easy enough to
> >> justify
> >>> fixing such a small bug.
> >>>
> >>> ----- Original Message -----
> >>> From: "Jim Graham" <james.graham at oracle.com>
> >>> To: "Denis Lila" <dlila at redhat.com>
> >>> Cc: 2d-dev at openjdk.java.net
> >>> Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada
> >> Eastern
> >>> Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on
> >> scaled lines.
> >>> I don't understand - why do we generate sample points based on
> the
> >> size 
> >>> of the cap?  Why not generate a pair of bezier quarter-circles
> and
> >> let 
> >>> the rasterizer deal with sampling?
> >>>
> >>> 			...jim
> >>>
> >>> Denis Lila wrote:
> >>>> Hello.
> >>>>
> >>>> I think I have a fix for this bug:
> >>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
> >>>>
> >>>> Basically, the problem is that if there is a magnifying affine
> >> transformation set on the graphics object and one tries to draw a
> line
> >> with small thickness and round end caps, the end caps appear
> jagged.
> >> This is because the computation of the length of the array that
> >> contains the points on the "pen" with which the decoration is
> drawn
> >> does not take into account the size of the pen after the
> magnification
> >> of the affine transformation. So, for example, if the line length
> was
> >> set to 1, and the transformation was a scaling by 10, the
> resulting
> >> pen would have a diameter of 10, but only 3 pen points would be
> >> computed (pi*untransformedLineWidth), so the end cap looks like a
> >> triangle.
> >>>> My fix computes an approximation of the circumference of the
> >> transformed pen (which is an ellipse) and uses that as the number
> of
> >> points on the pen. The approximation is crude, but it is simple,
> >> faster than alternatives
> >> (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can
> say
> >> from observations that it works fairly well.
> >>>> There is also icing on the cake, in the form of slight
> improvements
> >> in performance when the scaling is a zooming out. Example: if the
> >> original line width was 100, but g2d.scale(0.1,0.1) was set, then
> the
> >> resulting line would have a width of 10, so only ~31 points are
> >> necessary for the decoration to look like a circle, but without
> this
> >> patch, about 314 points are computed (and a line is emitted to
> each
> >> one of them).
> >>>> I appreciate any feedback.
> >>>>
> >>>> Regards,
> >>>> Denis Lila.
> >>>>


From dlila at redhat.com  Tue Jun 22 19:15:48 2010
From: dlila at redhat.com (Denis Lila)
Date: Tue, 22 Jun 2010 15:15:48 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
In-Reply-To: <801925137.668031277233771394.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <173792935.668431277234148269.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

I also have two questions about computing a good bezier approximation
to circle arcs.

1. Given the arc (1,0)->(cos(a),sin(a)) where 0<a<pi/2, will it result
in a good approximation to find the control points p1, p2 by solving
the equations imposed by the requirements B(1/3) = (cos(a/3), sin(a/3)
and B(2/3) = (cos(2a/3), sin(2a/3)). In other words, requiring that the
bezier curve go through two evenly spaced points in the arc.

2. If we have an affine transformation A which turns the circle arc in an
ellipse arc will the transformed control points Ap0, Ap1, Ap2, Ap3 define
a good bezier approximation to the ellipse arc?

Thank you,
Denis.

----- "Denis Lila" <dlila at redhat.com> wrote:

> That's true.
> 
> Well, if we're worried about the generated paths being verbose
> and taking long to process then the problem extends beyond just
> drawing round end caps. As far as I can see, whenever a path is
> drawn that doesn't consist only of straight lines (i.e. an ellipse),
> a flattening path iterator is being used to feed Stroker. So all
> the bezier curves are still broken down into tiny straight lines,
> just not by Stroker itself.
> 
> So, my question is, given a bezier curve C and a number w, is
> there a way of quickly computing the control points of two bezier
> curves C1, C2 such that the stuff between C1 and C2 is the widened
> path?
> More formally: compute the control points of C1, C2, where
> C1 = {(x,y) + N(x,y)*(w/2)  | (x,y) in C}
> C1 = {(x,y) - N(x,y)*(w/2)  | (x,y) in C}, where N(x,y) is the normal
> of C at (x,y).
> 
> If we could do this easily, then we can just make a new class that
> outputs bezier curves that is similar in purpose to Stroker, but that
> is used only when the output can handle bezier curves. This way, the
> only use left for Stroker would be when anti-aliasing, and for
> every thing else we wouldn't have to use a flattening path iterator.
> 
> Thanks,
> Denis.
> 
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
> 
> > Hi Denis,
> >
> > Consider the case of using BasicStroke.createStrokedShape().  How do
> > you
> > know how many pixels the resulting path will occupy?  You can't
> reduce
> >
> > to concrete samples if you don't know the transform.
> >
> > So, for rendering, then you may be correct.  But for cases where the
> > path is being asked for then beziers are the only responsible
> > solution...
> >
> > 			...jim
> >
> > Denis Lila wrote:
> > > Hello Jim.
> > >
> > > I thought about checking the output and changing the behaviour
> > > depending on whether the output is a PC2D or a LineSink, but I
> > didn't
> > > implement it because I thought the point was to get rid of the
> > sampling
> > > at this stage. However, if performance is the issue, then I guess
> > I'll
> > > start working on it.
> > >
> > > Although, I wonder whether it is really worth it. I think most
> lines
> > drawn
> > > won't be wider than about 5 pixels, which means that the current
> way
> > will
> > > emit about 7 lines, so that's 14 coordinates. 2 bezier quarter
> > circles will
> > > require 12 coordinates. In terms of storage, there isn't much
> > difference, and
> > > for lines of width 4 or smaller the current method is more
> > efficient.
> > >
> > > I'm also guessing that it's harder for the rasterizer to deal with
> > bezier
> > > curves than with straight lines, so is it possible that replacing
> > the
> > > 3.14*lineWidth/2 lines generated by the current method with 2
> bezier
> >
> > > quarter circles isn't worth it (for small lineWidths)?
> > >
> > > Thanks,
> > > Denis.
> > >
> > > ----- "Jim Graham" <james.graham at oracle.com> wrote:
> > >
> > >> Sigh - that makes sense.  One issue is that the resulting paths
> it
> >
> > >> generates are much more "verbose" than they need to be.  This
> would
> >
> > >> generally mean that it takes far more storage than it would
> > otherwise
> > >>
> > >> need - and it means that if the result needs to be transformed
> then
> > it
> > >>
> > >> would take many more computations to transform each segment than
> > the
> > >> bezier.
> > >>
> > >> So, perhaps it would be worth having it check the type of the
> > output
> > >> and
> > >> do either a bezier or a bunch of lines depending on if it is a
> PC2D
> > or
> > >> a
> > >> LineSink?
> > >>
> > >> Also, it isn't really that difficult to for Renderer to include
> > its
> > >> own
> > >> Cubic/Quadratic flattening code, but it might involve more
> > >> calculations
> > >> than the round-cap code since it would have to be written for
> > >> arbitrary
> > >> beziers whereas if you know it is a quarter circle then it is
> > easier
> > >> to
> > >> know how far to subdivide...  :-(
> > >>
> > >> 			...jim
> > >>
> > >> Denis Lila wrote:
> > >>> So, I have been thinking about this, and I can't see a good
> > >>> way to do it that wouldn't involve heavy changes to Pisces.
> > >>>
> > >>> In order for Stroker to generate Bezier quarter circles, it
> would
> > >>> have to implement a curveTo method, which means Stroker should
> > >>> start implementing PathConsumer2D and instead of using a
> LineSink
> > >>> output it would have to use a PathConsumer2D output (either
> that,
> > >> or
> > >>> LineSink should include a curveTo method, but then there won't
> > >> really
> > >>> be any difference between a LineSink and a PathConsumer2D. By
> the
> > >> way,
> > >>> LineSink doesn't have any implemented methods, so why is it an
> > >> abstract
> > >>> class as opposed to an interface?)
> > >>>
> > >>> Stroker is used in 3 ways:
> > >>> 1. As an implementation of BasicStroke's createStrokedShape
> > method.
> > >> This
> > >>> uses a Path2D object as output.
> > >>> 2. As a way of feeding a PathConsumer2D without calling
> > >> createStrokedShape
> > >>> to generate an intermediate Shape. This uses a PathConsumer2D
> > >> output.
> > >>> 3. As a way of feeding lines to a Renderer object, which
> > generates
> > >> alpha
> > >>> tiles used for anti-aliasing that are fed to a cache and
> > extracted
> > >> as needed
> > >>> by an AATileGenerator. Obviously, Stroker's output here is a
> > >> Renderer.
> > >>> 1 and 2 aren't problems, because the underlying output objects
> > >> support
> > >>> Bezier curves. 3, however, doesn't, and it seems like
> implementing
> > a
> > >>> curveTo method for Renderer would be very difficult because the
> > way
> > >> it
> > >>> generates alpha tiles is by scanning the drawn edges with
> > >> horizontal
> > >>> scan lines, and for each scan line finding the x-intersections
> of
> > >> the scan
> > >>> lines and the edges. Then it determines the alpha values (I'm
> not
> > >> too sure
> > >>> how it does this).
> > >>> In order to implement Bezier curves in Renderer, we would have
> to
> > >> have
> > >>> a quick way of computing, for each scan line, all its
> > intersections
> > >> with
> > >>> however many Bezier curves are being drawn.
> > >>>
> > >>> I haven't given much thought to how this could be done, as I am
> > not
> > >> very
> > >>> familiar with Bezier curves, but it doesn't seem easy enough to
> > >> justify
> > >>> fixing such a small bug.
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "Jim Graham" <james.graham at oracle.com>
> > >>> To: "Denis Lila" <dlila at redhat.com>
> > >>> Cc: 2d-dev at openjdk.java.net
> > >>> Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada
> > >> Eastern
> > >>> Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on
> > >> scaled lines.
> > >>> I don't understand - why do we generate sample points based on
> > the
> > >> size
> > >>> of the cap?  Why not generate a pair of bezier quarter-circles
> > and
> > >> let
> > >>> the rasterizer deal with sampling?
> > >>>
> > >>> 			...jim
> > >>>
> > >>> Denis Lila wrote:
> > >>>> Hello.
> > >>>>
> > >>>> I think I have a fix for this bug:
> > >>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
> > >>>>
> > >>>> Basically, the problem is that if there is a magnifying affine
> > >> transformation set on the graphics object and one tries to draw a
> > line
> > >> with small thickness and round end caps, the end caps appear
> > jagged.
> > >> This is because the computation of the length of the array that
> > >> contains the points on the "pen" with which the decoration is
> > drawn
> > >> does not take into account the size of the pen after the
> > magnification
> > >> of the affine transformation. So, for example, if the line length
> > was
> > >> set to 1, and the transformation was a scaling by 10, the
> > resulting
> > >> pen would have a diameter of 10, but only 3 pen points would be
> > >> computed (pi*untransformedLineWidth), so the end cap looks like a
> > >> triangle.
> > >>>> My fix computes an approximation of the circumference of the
> > >> transformed pen (which is an ellipse) and uses that as the number
> > of
> > >> points on the pen. The approximation is crude, but it is simple,
> > >> faster than alternatives
> > >> (http://en.wikipedia.org/wiki/Ellipse#Circumference), and I can
> > say
> > >> from observations that it works fairly well.
> > >>>> There is also icing on the cake, in the form of slight
> > improvements
> > >> in performance when the scaling is a zooming out. Example: if the
> > >> original line width was 100, but g2d.scale(0.1,0.1) was set, then
> > the
> > >> resulting line would have a width of 10, so only ~31 points are
> > >> necessary for the decoration to look like a circle, but without
> > this
> > >> patch, about 314 points are computed (and a line is emitted to
> > each
> > >> one of them).
> > >>>> I appreciate any feedback.
> > >>>>
> > >>>> Regards,
> > >>>> Denis Lila.
> > >>>>


From philip.race at oracle.com  Tue Jun 22 21:19:04 2010
From: philip.race at oracle.com (Phil Race)
Date: Tue, 22 Jun 2010 14:19:04 -0700
Subject: [OpenJDK 2D-Dev] 2 small xrender fixes
In-Reply-To: <AANLkTinQw4FROpNp5EWoQNgiv-EajrAMm9q_kU5rdtJZ@mail.gmail.com>
References: <AANLkTinOMS8Su9Qk-Zp5lQN0Sdx7knuUAnSvgblFvjhI@mail.gmail.com>
	<AANLkTinQw4FROpNp5EWoQNgiv-EajrAMm9q_kU5rdtJZ@mail.gmail.com>
Message-ID: <4C2128C8.8070302@oracle.com>


Clemens,

I thought I sent this email last week but I just found a very patient 
thunderbird compose window :-(

For the record, anyone with an openjdk user id should be able to
upload webrevs to cr.openjdk.java.net.

As to the fixes : The Jules one looks fine.
I can create you a bug ID.

The whitespace one, I'm not aware that T2K will do this.
I find that it sets it width and height to zero for whitespace.
I instrumented the rasteriser and ran  with code like this.

    public void paint(Graphics g) {
        Graphics2D g2d = (Graphics2D)g;

        g2d.setRenderingHint(
                 RenderingHints.KEY_TEXT_ANTIALIASING,
                 RenderingHints.VALUE_TEXT_ANTIALIAS_ON);

        Font f = new Font("Dialog", Font.PLAIN, 20);
        g.setFont(f);
        g.drawString("A C", 10, 20);

Are you running the published JDK7 build 97 ?
What is the exact platform and architecture?
Can you send me the test you are using?
Perhaps its even something in the exact font being used.
Can you send a pointer to that?

-phil.

Andrew John Hughes wrote:
> On 15 June 2010 14:40, Clemens Eisserer <linuxhippy at gmail.com> wrote:
>   
>> Hi,
>>
>> I would like to get two (very small) changes to the xrender-pipeline in:
>>
>> 1. http://93.83.133.214/ignore-whitespace-width.zip deals with the
>> fact that the closed-source
>> font rasterizer seems to generate width=65535 for whitespaces, which
>> resuts in software fallbacks.
>> Granted with height=0 rendering should be completly omited by the X
>> server, but as it seems it isnt.
>>
>> 2. http://93.83.133.214/synchronize-native-cairo-ops.zip
>> synchronize-native-cairo-ops synchronizes access to Jules's native
>> functions.
>> There seems to be a race somewhere in cairo and I wasn't able to hunt
>> it down, so synchronizing is the best I can do for now.
>>
>> Do I need to create two different bug-reports? Is OpenJDK Bugzilla enough?
>>
>>     
>
> You need a Sun bug ID (i.e. bugs.sun.com) for each, but it's quicker
> if an Oracle developer creates one.  Just ask for one when the patch
> is approved.
>
> It would be easier to read these if there were posted as patches or
> webrevs, not zips.
>
> Thanks,
>   



From linuxhippy at gmail.com  Wed Jun 23 14:50:36 2010
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 23 Jun 2010 16:50:36 +0200
Subject: [OpenJDK 2D-Dev] 2 small xrender fixes
In-Reply-To: <4C2128C8.8070302@oracle.com>
References: <AANLkTinOMS8Su9Qk-Zp5lQN0Sdx7knuUAnSvgblFvjhI@mail.gmail.com>
	<AANLkTinQw4FROpNp5EWoQNgiv-EajrAMm9q_kU5rdtJZ@mail.gmail.com>
	<4C2128C8.8070302@oracle.com>
Message-ID: <AANLkTikO53fWFk__RMfQWicdB7RsaqYN1yTLd0M-Eeev@mail.gmail.com>

Hi Phil,

> I thought I sent this email last week but I just found a very patient
> thunderbird compose window :-(
No problem, thanks for the reply

Until next week I am (again) really busy, after that I have plenty of
time to investigate the issue :)

I also have another fix which resolves some problems (disables an
optimization) with transformed-blits on intel-GPUs, and it would be
great to have all those fixes done in one go.
Is it ok to reduce transformation-precision if Graphics has
VALUE_RENDER_SPEED enabled?

Thanks, Clemens

> For the record, anyone with an openjdk user id should be able to
> upload webrevs to cr.openjdk.java.net.
>
> As to the fixes : The Jules one looks fine.
> I can create you a bug ID.
>
> The whitespace one, I'm not aware that T2K will do this.
> I find that it sets it width and height to zero for whitespace.
> I instrumented the rasteriser and ran ?with code like this.
>
> ? public void paint(Graphics g) {
> ? ? ? Graphics2D g2d = (Graphics2D)g;
>
> ? ? ? g2d.setRenderingHint(
> ? ? ? ? ? ? ? ?RenderingHints.KEY_TEXT_ANTIALIASING,
> ? ? ? ? ? ? ? ?RenderingHints.VALUE_TEXT_ANTIALIAS_ON);
>
> ? ? ? Font f = new Font("Dialog", Font.PLAIN, 20);
> ? ? ? g.setFont(f);
> ? ? ? g.drawString("A C", 10, 20);
>
> Are you running the published JDK7 build 97 ?
> What is the exact platform and architecture?
> Can you send me the test you are using?
> Perhaps its even something in the exact font being used.
> Can you send a pointer to that?
>
> -phil.
>
> Andrew John Hughes wrote:
>>
>> On 15 June 2010 14:40, Clemens Eisserer <linuxhippy at gmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> I would like to get two (very small) changes to the xrender-pipeline in:
>>>
>>> 1. http://93.83.133.214/ignore-whitespace-width.zip deals with the
>>> fact that the closed-source
>>> font rasterizer seems to generate width=65535 for whitespaces, which
>>> resuts in software fallbacks.
>>> Granted with height=0 rendering should be completly omited by the X
>>> server, but as it seems it isnt.
>>>
>>> 2. http://93.83.133.214/synchronize-native-cairo-ops.zip
>>> synchronize-native-cairo-ops synchronizes access to Jules's native
>>> functions.
>>> There seems to be a race somewhere in cairo and I wasn't able to hunt
>>> it down, so synchronizing is the best I can do for now.
>>>
>>> Do I need to create two different bug-reports? Is OpenJDK Bugzilla
>>> enough?
>>>
>>>
>>
>> You need a Sun bug ID (i.e. bugs.sun.com) for each, but it's quicker
>> if an Oracle developer creates one. ?Just ask for one when the patch
>> is approved.
>>
>> It would be easier to read these if there were posted as patches or
>> webrevs, not zips.
>>
>> Thanks,
>>
>
>


From philip.race at oracle.com  Tue Jun 29 16:52:11 2010
From: philip.race at oracle.com (philip.race at oracle.com)
Date: Tue, 29 Jun 2010 16:52:11 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6943487: NPE in
	makeMultiCharsetString while	printing on linux
Message-ID: <20100629165256.E3B3647617@hg.openjdk.java.net>

Changeset: c801686d91f4
Author:    prr
Date:      2010-06-29 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c801686d91f4

6943487: NPE in makeMultiCharsetString while printing on linux
Reviewed-by: igor, jgodinez

! src/share/classes/sun/awt/PlatformFont.java
! src/share/classes/sun/java2d/HeadlessGraphicsEnvironment.java