[
https://issues.apache.org/jira/browse/PDFBOX-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230599#comment-15230599
]
Tilman Hausherr edited comment on PDFBOX-3089 at 4/7/16 7:49 PM:
-----------------------------------------------------------------
Writing down some thoughts, because I'm not working on this every day...
- happens with "ö" in the TimesNewRomanPSMT truetype font
- gid: 180, code: 148
- made of gid 180 and 196 (composite glyph)
- GlyphTable.getGlyph(196) is called 436 \(!) times
- GlyphRenderer.describe() calls GlyphDescription.getXCoordinate\(i) and
GlyphDescription.getYCoordinate\(i)
- in GlyfCompositeDescript, these call getGlypDescription() which calls
GlyphTable.getGlyph() again :-(
- GlyphRenderer.describe() also calls GlyphDescription.getEndPtOfContours(),
same problem. However this can be optimized because it is called several times
with the same parameter
- After optimizing the getEndPtOfContours() calls, count is down to 344
- getCompositeComp() sometimes calls getGlypDescription() even if the result is
not used \(if the first part of the "if" statement below is false)
- optmizing that brings the count down to 343 so it isn't important
- in describe(), gd.getXCoordinate\(i), gd.getYCoordinate\(i) and
gd.getFlags\(i) all call getCompositeComp\(i) with the same value if gd is
composite
- possible solution: move {{new Point(gd.getXCoordinate\(i),
gd.getYCoordinate\(i),(gd.getFlags\(i) & GlyfDescript.ON_CURVE) != 0, endPt);}}
into the two GlyphDescription classes, parameter i and endPt.
- count down to 151
- todo investigate if it is somehow possible to change the software so that the
GlyfCompositeComp object is kept for all values of i.
was (Author: tilman):
Writing down some thoughts, because I'm not working on this every day...
- happens with "ö" in the TimesNewRomanPSMT truetype font
- gid: 180, code: 148
- made of gid 180 and 196 (composite glyph)
- GlyphTable.getGlyph(196) is called 436 (!) times
- GlyphRenderer.describe() calls GlyphDescription.getXCoordinate(i) and
GlyphDescription.getYCoordinate(i)
- in GlyfCompositeDescript, these call getGlypDescription() which calls
GlyphTable.getGlyph() again :-(
- GlyphRenderer.describe() also calls GlyphDescription.getEndPtOfContours(),
same problem. However this can be optimized because it is called several times
with the same parameter
- After optimizing the getEndPtOfContours() calls, count is down to 344
- getCompositeComp() sometimes calls getGlypDescription() even if the result is
not used (if the first part of the "if" statement below is false)
- optmizing that brings the count down to 343 so it isn't important
- in describe(), gd.getXCoordinate(i), gd.getYCoordinate(i) and gd.getFlags(i)
all call getCompositeComp(i) with the same value if gd is composite
- possible solution: move {{new Point(gd.getXCoordinate(i),
gd.getYCoordinate(i),(gd.getFlags(i) & GlyfDescript.ON_CURVE) != 0, endPt);}}
into the two GlyphDescription classes, parameter i and endPt.
- count down to 151
- todo investigate if it is somehow possible to change the software so that the
GlyfCompositeComp object is kept for all values of i.
> Investigate why glyph path caching does not always cache glyph accesses
> -----------------------------------------------------------------------
>
> Key: PDFBOX-3089
> URL: https://issues.apache.org/jira/browse/PDFBOX-3089
> Project: PDFBox
> Issue Type: Task
> Components: FontBox
> Affects Versions: 2.0.0
> Reporter: Tilman Hausherr
> Priority: Minor
> Labels: Optimization
> Fix For: 2.1.0
>
>
> Work in PDFBOX-3088 shows that despite caching glyph paths in
> TTFGlyph2D.getPathForGID(), there are repeated accesses for the same gid in
> GlyphTable (which is why that one is now cached as well).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
