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

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout.
From:       Prahalad Kumar Narayanan <prahalad.kumar.narayanan () oracle ! com>
Date:       2017-12-11 13:10:48
Message-ID: 332230c2-15b6-4101-b078-74c1ea906e3f () default
[Download RAW message or body]

Hello Phil

The change looks good to me.

I found two interesting changes in your webrev. 
. The move to use FontDesignMetrics to compute width should be better than generating \
                GlyphVector for the same.
. Besides, the double conversion from chars[] to String and vice versa has been \
avoided as well.

Thank you
Have a good day

Prahalad

-----Original Message-----
From: Phil Race 
Sent: Friday, December 08, 2017 2:24 AM
To: 2d-dev; swing-dev@openjdk.java.net
Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text \
layout.

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.


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