[OpenJDK 2D-Dev] <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 2d-dev
mailing list