Question/discussion about JDK-8129582

[Philip Race]

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