[OpenJDK 2D-Dev] <Swing Dev> RFR: 8189809: Large performance regression in Swing text layout.

Phil Race philip.race at oracle.com
Mon Dec 11 22:39:54 UTC 2017


Yes, it should  be negative since we want to use this as the y origin of 
the rectangle
relative to the baseline. I am using it correctly in the height calculation.

40 float height = ascent + descent + leading;
541 return new Rectangle2D.Float(0f, ascent, width, height);


http://cr.openjdk.java.net/~prr/8189809.1/

-phil.

On 12/11/2017 02:12 PM, Sergey Bylokhov wrote:
> 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.
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20171211/1ac1a79e/attachment.html>


More information about the 2d-dev mailing list