commit head: new handling of justification finished

From: Tomas Frydrych (
Date: Fri Jul 26 2002 - 10:12:40 EDT

  • Next message: Tomas Frydrych: "Re: performance issues"

    files: fp_TextRun.cpp/h, fp_Line.cpp

    The new algorithm requires a few words of explanation. The old
    algorithm worked like this: if the run was to be justified, we split it so
    that each continous span of spaces was contained in its own run.
    We then divided the extra width needed to justify our run between
    the spaces and adjusted the withds of the space-only runs
    accordingly. This was costly in terms of memory and drawing
    performance; each justification point required two runs to represent
    it, i.e., 2 * sizeof(fp_TextRun), 368 bytes (as of now).

    The new algorithm avoids the costly spliting of runs by doing only a
    notional split. Every continous span of spaces is described by a
    record of four int's: offset of the spaces from the start of the run,
    length of the span, its (adjusted) width and the width of the text span
    that precedes it. This information is stored in a vector
    m_pJustifiedSpaces and is processed by fp_TextRun::_draw(). Thus
    the overall memory requirenment for each justification point is 4 *
    sizeof(void*), 16 bytes; this amounts to saving 352 bytes per
    justification point, i.e., in a fully justified document of 5000 words we
    should use roughly 1.7 MB of memory less !!!

    A further advantage of this is that since the extra advance on the
    screen is handled inside of a singe call to fp_TextRun::_draw(),
    rather than in between several separate calls to the routine, our
    drawing performance improves because we get rid of the overhead
    that the separate calls required (drawing selection background,
    setting up colours, etc.). In return
    ::distributeJustificationAmongSpaces(), ::split() and
    ::mergeWithNext() become slightly more complex.

    I have completely removed all of the old code, simply because there
    were too many #ifdef's and the code became too unreadable.
    AFAIK the new stuff works, but there is a great scope for bugs, and
    so I am inclined to think we should not backport this, certainly not
    for now.


    This archive was generated by hypermail 2.1.4 : Fri Jul 26 2002 - 10:21:35 EDT