Uwe Stöhr wrote:
Dov Feldstern schrieb:
Can you try the attached "patch" to see if it speeds things up? Note
that this is not really a patch --- the painting will be *incorrect*
with it applied; but it's just to diagnose whether the problem is
where I think it is.
Your "patch" solves the problem for me.
regards Uwe
Hmmm..., this means that the main slowdown stems from the fact that we paint RTL
text a character-at-a-time instead of a word-at-a-time.
The reason we do that is that we have already performed our own bidi on the
strings passed to Qt for painting, but Qt applies its own bidi algorithm, the
end result being that the strings are painted backwards.
We have already applied bidi internally, because we use that information
extensively in other settings besides painting --- high-level layout (metrics)
and cursor movement being the main places that I'm aware of.
I basically see three approaches for solving this issue:
(1) Get Qt to offer an option for painting which says "already visual, don't
apply bidi". In fact, I'm pretty sure that when I was originally looking into
the bidi problems in pre-1.5 LyX, I saw that Qt has such an option in their
internal API, but it's not exposed; so it may not be hard for them to offer such
an option.
(2) Perhaps we could re-apply our bidi algorithm again just before passing the
strings to Qt. That would mean that bidi is applied to the strings 3 times
instead of once, which sounds a bit wasteful, but it's probably negligible next
to the cost of the painting.
(3) Perhaps we could entirely re-work our handling of bidi, such that we would
not need our own bidi at all, and could rely entirely on Qt for providing this
service. I think this would require major reworking, since, as explained, we use
bidi information not only for painting, and I'm not sure how that would work.
Personally, (1) seems like the easiest solution for us (it also best represents
what we really want to do); but it would only work for users using Qt versions
which would support this option. Should we file an enhancement request with Qt?
(3) would require major work, and it would also break GUI independence (if we
still care about that at all); however, it might be the cleanest solution in the
long term. (2) might be a good compromise, which would allow us to apply a
relatively quick patch, without needing third-party assistance.
BTW, I'm afraid I won't have much time to put into this anytime soon... If
there's anyone who wants to pursue this, though, I can try and help out.
Anyhow, I opened a bug for this issue, we should move the discussion there
http://bugzilla.lyx.org/show_bug.cgi?id=5188 .
Dov
