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

["Charles Moir" <CharlesM@xxxxxxxx>]

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.

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.

Charles


> -----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
> >
>