The cache is a heuristic optimisation and whether it helps depends on
how well that cache is used.
It is a time-space trade-off and I'd expect it to show up as helping
more in micro-benchmarks or
text-intensive benchmarks which use the same text broken in the same way.
Complex text layout is inherently slower and if you are doing a lot of
it .. it will be slow .. and
unless it is repeated a cache won't help.
During start-up I'd *expect* that there isn't a lot of re-use going on.
You would need to profile how often the same text (and attributes) are
passed through this code.
If you could provide us a test case we could examine it too.
If it were a real use case, then we'd move on to examine the feasibility
of caching ...
-phil.
On 1/4/17, 9:19 AM, Itai wrote:
Recently JDK-8129582 [1] started really affecting me, with startup speed
and overall responsiveness becoming really bad.
Digging into it, I have found most time is wasted in
com.sun.javafx.text.GlyphLayout.layout (as represented by PangoGlyphLayout
on my Linux machine), which in turn is called
by com.sun.javafx.text.PrismTextLayout.shape, which has:
if (run.isComplex()) {
/* Use GlyphLayout to shape complex text */
layout.layout(run, font, strike, chars);
} else {
...
if (layoutCache == null) {
...
} else {
...
}
}
which to my very naive reading seems as if while non-complex (with all BiDi
text considered complex) glyph runs are cached, complex runs are never
cached, which forces re-calculation every time.
I'm trying to read and understand this part better, but could it be
possible that this is the issue? How feasible would it be to have a layout
cache for complex runs, or at least non-complex BiDi runs?
Thanks,
Itai.
[1]: https://bugs.openjdk.java.net/browse/JDK-8129582
