<Swing Dev> RFR: 8189809: Large performance regression in Swing text layout.

[Phil Race]

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.