Thanks for replying.
I think I understand what you're saying about the cache. As for complexity
- I'm mostly working with text which is only in Hebrew, which isn't complex
as far as I understand the definition (no glyph "fusing" as in Arabic or
Farsi). I can work with minor performance drops, but when the same window
takes more than 10 times to show if it has Hebrew labels is a lot more than
minor - and this is exclusive to JavaFX, so it's not like this problem is
unsolvable.
Perhaps the caching is indeed not the correct solution, but maybe there can
be a way to simplify the layout in non-complex BiDi cases? Or optimize
PangoGlyphLayout.layout?
Thank you again for replying, I really hope this issue can see some
improvement.
On Wed, Jan 4, 2017 at 7:26 PM, Philip Race <philip.r...@oracle.com> wrote:
> 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
>>
>
