RFR: 8304350: Font.getStringBounds calculates wrong width for TextAttribute.TRACKING other than 0.0

[Jonathan Dowland]

On Sun, 9 Apr 2023 16:39:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
>> 
>> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a heuristic to determine whether the question it's answering is "simple" or not. The bug described in 8304350 only occurs in the simple=true branch.
>> 
>> Extend the "simple?" heuristic to consider a tracking attribute not-simple and to use the complex branch in those cases.
>> 
>> One could argue that the root bug still exists: the simple path goes on to delegate to `sun.font.FontDesignMetrics.getMetrics(Font,FontRenderContext)`, although that's a private/internal API.
>
> Seems like a reasonable workaround. Would there be any measurable performance impacts by going the more complex route with Tracking != 0?

@tstuefe wrote:
> Seems like a reasonable workaround.

Thanks for your feedback!

>  Would there be any measurable performance impacts by going the more complex route with Tracking != 0?

I suspect so, because I expect that performance is the reason the simple path was added. I just tried a simple JMH-based benchmark (I'll push the source for the test app somewhere shortly) based on a PDF renderer which relies upon Tracking for correct operation. It's definitely slower with the patch. Without:

    Benchmark       Mode  Cnt     Score     Error  Units
    App.pdfwriter  thrpt   25  6466.086 ± 52.114  ops/s

with:

    Benchmark       Mode  Cnt     Score    Error  Units
    App.pdfwriter  thrpt   25  5894.784 ± 56.380  ops/s

That said; there's fast, and then there's correct...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13352#issuecomment-1503936821