Question/discussion about JDK-8129582

[Itai]

Thank you for the link, it's an interesting read indeed!

I wasn't really skipping layout, just using the much simpler layout used by
Latin scripts, but you are correct that this will break for anything more
complex - this has nothing to do with BiDi though, more to do with complex
layout elements (like diacritic or cantillation marks for Hebrew, or
general Arabic/Farsi text).
Indeed, this can't be a general solution, but I guess I was driven by
frustration.

I have tried some more configurations though, and found that on Windows the
loss of performance is much less noticeable, which seems to mean that the
problem is either:
1. Pango is inherently slow / inherently slow when laying out BiDi text.
2. JavaFX uses Pango in a sub-optimal / redundant way.
3. The JNI / native calls to Pango are done in a sub-optimal way.

Option 1 can be easily debunked, as general Gnome/GTK applications run as
smoothly with BiDi text as with Latin / LTR text.
For options 2 and 3 I guess some more digging into the code must be done.
My understanding is that JNI calls are not likely to incur performance loss
to such a degree, unless very large amounts of memory are copied back and
forth between Java and native code, so I'll start by reading into the Pango
documentation and understanding the logic of PangoGlyphLayout.

If you have any input on this or believe my assumptions or conclusions are
wrong I'd be glad to hear. I realize you are all busy with the upcoming 9
release, so I'll try to get as detailed a result as I can.

Regards,
Itai.

On Wed, Jan 4, 2017 at 8:44 PM, Phil Race <philip.race at oracle.com> wrote:

> You can't skip layout just because it is bidi ..
> where here you are apparently implicitly meaning Hebrew.
> This might be apparently working but may not always work even
> for Hebrew and will be a disaster for Arabic.
>
> Here is a web page which talks about OTL (OpenType Layout) for Hebrew :
> https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm
> I can't say offhand why this might be exclusive to FX.
> That test case would be handy.
> So this needs more analysis even if you found a way to limit this to
> specifically Latin+Hebrew.
>
> -phil.
>
>
> On 01/04/2017 10:32 AM, Itai wrote:
>
> Some quick-and-dirty thing I hacked now and seems to improve the
> performance drastically is something like:
>
> if (complex but not bidi) {
>    use GlyphLayout.
> } else if (bidi) {
>    use java.text.Bidi.reorderVisually to get visual glyph order, then use
> same implementation as non-bidi non-complex layout
> } else {
>    ...
> }
>
> Very minimal tests show it working correctly, and performance is 8-10
> times faster (on par with non-bidi text).
> Do you think this solution makes sense? Can you see any obvious pitfalls?
> If it seems OK I'll try some more tests and then work it into something
> clean enough to submit as a patch suggestion.
>
>
> On Wed, Jan 4, 2017 at 7:48 PM, Itai <itaisha at gmail.com> wrote:
>
>> 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.race at oracle.com>
>> philip.race at 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
>>>>
>>>
>>
>
>