[OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout.
Prahalad Kumar Narayanan
prahalad.kumar.narayanan at oracle.com
Mon Dec 11 13:10:48 UTC 2017
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.
Have a good day
From: Phil Race
Sent: Friday, December 08, 2017 2:24 AM
To: 2d-dev; swing-dev at openjdk.java.net
Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout.
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.
More information about the 2d-dev