RFR: 8304350: Font.getStringBounds calculates wrong width for TextAttribute.TRACKING other than 0.0
Jonathan Dowland
jdowland at openjdk.org
Tue Apr 11 19:00:34 UTC 2023
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
More information about the client-libs-dev
mailing list