Re: Commit: fonts part 2 & 3


Subject: Re: Commit: fonts part 2 & 3
From: Jesper Skov (jskov@cambridge.redhat.com)
Date: Mon Mar 19 2001 - 12:38:26 CST


>>>>> "Paul" == Paul Rohr <paul@abisource.com> writes:

Paul> You've just described Jeff's underlying attrprop mechanism as
Paul> used in the Piece Table. As an experiment, why not try

Ah, I should have known. I've been debugging stuff which refers to
property indexes.

Paul> profiling some mods which do lookups against the AP directly,
Paul> instead of from the cached copies in each Run?

Paul> Off the cuff, I'm not sure you'll see the kind of impact you
Paul> want. Consider which operation is more common:

Paul> - drawing or doing other calculations from an existing run -
Paul> splitting runs due to edit operations

Paul> The idea of caching run-level props is to mimimize the amount of
Paul> code it takes to draw, which ought to be the most common
Paul> operation in a GUI app. Or are you seeing nasty delays during
Paul> typing?

Ah! These are cached copies of properties. I'm sorry if I offend, but
I just have to say: how incredibly crude :)

So there's a nice indexed property array with all the info needed to
render a Run. To speed up rendering, instead of improve the way to
access this information, it gets copied to each and every Run.

That's like reverse-caching (assuming "normal" caching is a way of
concentrating the information you access often in the same location -
here it gets spread out :)

Paul> On a related note, one of the chief sources of run bloat today
Paul> is the fact that runs aren't properly coalesced when typing.
Paul> When Jeff and I originally implemented editing, we did all the
Paul> work necessary to make sure that additional characters typed
Paul> with the same property would be appended to the same run, and
Paul> runs would only be split by the line breaker. (We also thought
Paul> about rejoining such runs when the content got reflowed, but I
Paul> don't think we bothered implementing that.)

I've always been puzzled by this. Seeing as the undo information is
represented as indexes in the PT it seems obvious to to continuous
coalescelation(?) of Runs while typing - that (undo) is the only thing
I could think of that would have wanted single-char Runs.

Paul> However, quite a while ago either Eric or Bruce introduced a
Paul> change to force every character typed into its own run. (Ick.)
Paul> IIRC, this might have been part of the effort to fix character
Paul> overhang problems, but I'm not sure. You'll have to ask them.
Paul> :-)

Paul> If you're concerned about run bloat, you might want to look at
Paul> what would happen if we *did* go back to coalescing runs
Paul> properly instead.

Hm... I think I've just canned all plans for hacking more on the
existing implementation. As has just been demonstrated (again) there
are too many design decisions / hacks to the code which is not
documented - and as I'm not paid to work on AbiWord there's just too
little time for me to discover all this by reading the code and piece
it together from that. *sigh*

I'll stick to fixing the odd interesting bug and look at integrating
Pango support.

Thanks for the info, Paul!

Cheers,
Jesper



This archive was generated by hypermail 2b25 : Mon Mar 19 2001 - 12:38:29 CST