Subject: Re: RFC on layout code performance
From: Jesper Skov (jskov@cambridge.redhat.com)
Date: Fri Mar 16 2001 - 16:31:03 CST
>>>>> "Diego" == Diego Sueiro <dhsueiro@yahoo.com> writes:
Diego> 1) We can rule out long text runs at all, breaking them into
Diego> several ones ( don't know enough about abi's backend yet to be
Diego> sure whether this makes sense or not ).
AbiWord formats a paragraph by stuffing all Runs on a single line and
break it down into multiple lines from there. Having multiple Runs
will not make a great difference. See below.
Diego> 2) Cache some data in the text run to avoid recomputing
Diego> thousand of times TextRun::getWidthInLayoutUnits() ( that was
Diego> happend in the case I saw, though the TextRun was being breaked
Diego> each time, so a quick hack wouldn't apply ).
Diego> 3) Modify fb_LineBreaker::breakParagraph(fl_BlockLayout*) to
Diego> re-use some calculated results whenever a TextRun is broken in
Diego> two, to speed up the process.
Disagree. What we need is a different algorithm, not caching. I
haven't looked at the code in detail because, well, there were bugs to
fix, and I'm not even sure I want to spend more time on the existing
backend (think pango).
However, I have noticed several functions that look overly complex for
what they do. And as with the findPointCoords stuff I cleaned up a
while back, some of it would improve immensely by changing the way the
code works (e.g., move some controls up in the callchain, make lower
calls simpler and faster).
I'd really hate to see the current backend code be made even more
cryptic and fragile by adding caching of Runs and/or their attributes
in an attempt to get performance improvement. There are better ways to
do it - trust me.
If you want to help, please consider doing it by fixing bugs. We can
make it work faster when it's free of bugs (otherwise you'll just make
it crash faster ;)
Jesper
This archive was generated by hypermail 2b25 : Fri Mar 16 2001 - 16:31:09 CST