Re: fp_TextRun coalescing weirdness

>
> J.M. Maurer wrote:
>>> There are some circumstances where runs cannot/will not be merged;
>>> those
>>> are defined by fp_TextRun::canMergeWithNext() and
>>> GR_*RenderInfo::canAppend(); this includes not merging runs past word
>>> boundaries,
>>
>> What is the reason that we do not merge across word boundaries (I'm not
>> too much into this area yet)? It sounds not-optimal to me.
>
> The comment near bottom of fp_TextRun::canMeregeWithNext() says it is to
> reduce flicker. I do not recall adding that myself though, and am not
> sure it should be necessary (it would be good to know where exactly that
> flicker was coming from with long runs; there might be a better way of
> fixing it). Certainly having a run per word increases the memory
> footprint quite a bit (last time I checked fp_TextRun required around
> 150 bytes).
>
>> BTW, when you paste the whole string in, it will become 1 run.
>
> Yes, when you paste it in, it gets inserted as a single run to start
> with, and only gets broken into pieces if GR_Graphics::itemize() tells
> us it needs to be broken, or when it runs over the end of the line.
>

I think the idea for reducing flicker is as follows. When you press a key,
the old run gets cleared, and then redrawn with the new key. If there is
one run per line, then the whole line gets cleared then redrawn. This
gives substantial flicker. Limiting the clearing and redrawing to on word
cuts down on this substantially.

Cheers

Martin

> Tomas
>
>
Received on Wed Apr 11 02:32:53 2007