[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] <Swing Dev> RFR: 8189809: Large performance regression in Swing text layout.
From:       Sergey Bylokhov <Sergey.Bylokhov () oracle ! com>
Date:       2017-12-11 22:56:02
Message-ID: 41ed31d9-8959-28d7-818a-a892a078eef6 () oracle ! com
[Download RAW message or body]

Looks fine.

On 11/12/2017 14:39, Phil Race wrote:
> 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.
>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.
[prev in list] [next in list] [prev in thread] [next in thread]