RE: [XaraXtreme-dev] Font metrics and kerning update

[Martin Wuerthner <lists@xxxxxxxxxxxxxxx>]

In message <5056CBC646CB4047BB26120F4377DB719BA2FE@xxxxxxxxxxxxxxxxxxx 
>
          "Charles Moir" <CharlesM@xxxxxxxx> wrote:

> I was not aware that we did any font position caching, but I might be
> wrong. I thought we rendered the characters outlines on the fly at the
> appropriate position. But I could be wrong.

Fortunately, there are no calls to FreeType during rendering at all. 
The outlines are cached and each character object remembers its 
position after the last reformat. So, at the moment, the kerning 
information is only read during reformatting. Even entering a new 
character does not cause the preceding kerns to be reread, just the 
new kerning pair. Most other reformatting operations cause all 
required kerning pairs to be reread though, e.g., changing the column 
width.

> As to kerning metrics, assuming we do not need it for fast rendering (on
> the basis that we do cache character positions) but text formatting
> really needs to be a real-time operation. i.e. we should be able to
> alter the columns widths and have text reformatted and rendered on the
> fly during the column width change (and given our competitors can this
> is not really an option any more).  So again there really should not be
> any system calls during text formatting either, if we can avoid it.

Yes, I agree. I have done a quick test and having kerning switched on 
really is a performance killer when reformatting large blocks of text. 
There is no need for a benchmark, you can see the slowness 
immediately.

I will have a go at a kerning pairs cache. As you suggested, it should 
not be too difficult to add. I do not think any of the existing caches 
can help.

Martin

>> -----Original Message-----
>> From: owner-dev@xxxxxxxxxxxxxxxx
>> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Jonathan Payne
>> Sent: 19 April 2006 19:15
>> To: dev@xxxxxxxxxxxxxx
>> Subject: Re: [XaraXtreme-dev] Font metrics and kerning update
>> 
>> Hello,
>> 
>> I wrote the original kerning code for Xara X so I might be
>> able to add something to this discussion.
>> 
>> I seem to remember the cache size is small because there was
>> little advantage in making it any larger.  You gain the most
>> from the cache when you are rendering a large amount of text
>> which would typically be in the same font.  In that case, the
>> code caches the kerning pairs for the font the user has
>> selected to avoid having to make lots of slow operating
>> system calls for each character.  The cache allows for more
>> than one font  so the user does not get bad performance if
>> they happen to include a word or two in a different font in a
>> large block of otherwise plain text.  For a small block of
>> text, the overhead of a few operating system calls should be
>> negligible so the total number of fonts used in a document
>> isn't too important.
>> 
>> I remember doing some benchmarks and found that the cache made a
>> reasonable difference with large text blocks.   As for the point Alex
>> raised about not reformatting on every draw, I don't remember
>> if the code has this optimisation (I suspect it does) but
>> even so, a cache is still useful as reformatting could be
>> quite frequent.  For example I think most of these operations
>> could cause reformats: sizing text, changing fonts, contours
>> and blends.
>> 
>> Hope this helps.
>> 
>> Jonathan
>> 
>> On 19/04/06, Alex Bligh <alex@xxxxxxxxxxx> wrote:
>> >
>> >
>> > --On 19 April 2006 18:01 +0100 Charles Moir
>> <CharlesM@xxxxxxxx> wrote:
>> >
>> > > But without any caching does that mean we'd have to call Freetype
>> > > during display? That sounds a recipe for really slow text
>> > > rendering.
>> >
>> > Whilst I'm sure (re)introducing a cache is a good idea and I agree
>> > with Martin's comments re the inadvisability of reading up
>> > to (2^32)^2
>> > kerning pairs ( :-) ), I don't actually see how this affects
>> > /rendering/ speed.
>> >
>> > Is rendering done from an outline cache, and the positions of those
>> > outlines themselves are (surely) cached when the text is formatted?
>> > Surely the worst this can do is affect formatting speed?
>> (yes I agree
>> > it would still be a good plan to fix it). I hope we are not doing a
>> > reformat every time we do a rerender.
>> >
>> > Alex