--- Tomas Frydrych <[EMAIL PROTECTED]> wrote:
>
> > yes, it was only left aligned. Not fully
> justified.
>
> Then there seems to be something wrong with your
> figures, since
That's not the logical conclusion. The logical
conclusion is that there seems to be something wrong
with the code
> we really only have one run per line of uniformly
> formatted text, runs
> are coalesced in every call to
> fl_BlockLayout::formatLocal(), and the
> code there, AFAICT works.
ok, formatLocal coalesces runs, but before that, we're
creating ~2 runs by word, and we're calling plenty of
PP_evalProperty due to that (which turns to do a lot
of calls to the hash, more than 20 millions).
We *create* 165382 runs in the document. Looking at
the code:
bool fl_BlockLayout::_doInsertTextSpan(PT_BlockOffset
blockOffset, UT_uint32 len)
{
[...]
while(len > curOffset - blockOffset)
{
[...]
for(i = 1; i < trueLen; i++)
{
iPrevType = iType;
iType = fribidi_get_type((FriBidiChar)pSpan[i]);
if(iType != iPrevType)
break;
}
xxx_UT_DEBUGMSG(("_doInsertTextSpan: text run:
offset %d, len %d\n", curOffset, i));
fp_TextRun* pNewRun = new fp_TextRun(this,
m_pLayout->getGraphics(), curOffset, i);
[...]
}
So we're creating a run each time fribidi type of a
character changes. English chars and spaces don't
have the same fribidi type, so at this point we're
splitting several runs.
Btw, just removing some spurious PP_evalProperty and
caching a bit here and there I've lowered the number
of hash accesses from 21 millions to 16 millions. I
hope that if we solve this problem with the runs, the
number of hash accesses will reduce much more. (The
time we pass in the hash is at least 40% of the load
time.)
Cheers,
=====
Joaquin Cuenca Abela
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
