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 <itai...@gmail.com
<mailto:itai...@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.r...@oracle.com <mailto: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
<https://bugs.openjdk.java.net/browse/JDK-8129582>
