<Swing Dev> RFR: 8189809: Large performance regression in Swing text layout.

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Mon Dec 11 22:12:21 UTC 2017

Hi, Phil.
The new code will calculate the logical bounds this way:
     541 new Rectangle2D.Float(0f, ascent, width, height);
But previously it was:
     2613 new Rectangle2D.Float(0, -tl.getAscent(),   tl.getAdvance(),
     2614                       tl.getAscent() + tl.getDescent() +
     2615                       tl.getLeading());

Note that the second parameter is negative, is it intentionally changed?

On 07/12/2017 12:54, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189809
> webrev: http://cr.openjdk.java.net/~prr/8189809/
> This partially addresses a slow-down in Swing.
> Swing now usually calls Font.getStringBounds() instead of 
> FontMetrics().stringWidth for text measurement.
> The latter has a fast-path for latin-only simple text.
> The former does not .. and at a minimum uses GlyphVector.
> This fix provides a similar fast path and for direct calls to these 
> methods (micro benchmarks)
> that is latin text they are now very similar .. at least for typical 
> strings.
> In this fix as well as making this change in the font code, I updated 
> Swing to more
> be a little more efficient.
> Before this fix I always saw Swing  coming in with a char[] .. then 
> constructing a String from it.
> Then it passes it to the font measurement code, which then decomposes 
> the string back into a char[]
> If Swing directly uses the API that takes a char[] then we save some 
> overhead.
> It does not get back all of the loss by Swing since
> 1) Swing has other overhead elsewhere - it seems
> 2) Swing is making 90% of these calls for a single char.
> This could be from where Swing naively tries to add up char advances 
> itself to
> get a string advance.
>      We may have to come back to that later. Perhaps with new public API.
> -phil.

Best regards, Sergey.

More information about the swing-dev mailing list