[cairo] text measuring speed

[Jon Smirl]

On 6/11/05, Owen Taylor <otaylor at redhat.com> wrote:
> > Ok, if I understand correctly Pango has replaced freetype with an
> > equivalent for PDF/Win32 on these platforms. The replacement lives in
> > Cairo. That allows it to share the font cache with the render stage.
> > So pango doesn't call freetype directly any more, it instead calls
> > Cairo which passes the calls out to freetype/PDF/win32/etc. Right?
> 
> Not really. For PDF, we are using FreeType on Linux/Unix ...but the
> point is that the PDF backend for Cairo needs to have access to the
> font data in order to subset the font and embed it into the PDF file.

Wouldn't it be cleaner to remove all direct access to freetype from
Pango and use Cairo instead? That would make it transparent to pango
when switching from win32/PDF/xft.

> > But pango deals with kerned strings generated by
> > freetype/PDF/win32/etc right? Not individual glyphs.
> >
> > So back to my initial question, why does Keith care about the speed of
> > GetTextExt() on a single glyph if pango is deals in kerned strings?
> 
> Because Pango has to find out the size of the single glyphs when it
> is kerning the strings...

That was one mistake in my understanding, I thought the font libraries
were providing the kerned strings. But the font libraries aren't
smarted enough to kern in two dimensions so pango does it instead.

So why does Cairo have a performance problem with GetTextExt(), isn't
it just a thin wrapper for GetTextExt() being supplied by
xft/PDF/Win32? Cairo would cache the glyph info and return it as
needed.

I can see that Win32 may have trouble since Cairo is caching something
that is already cached by the OS. Freetype the cache is optional, not
sure how PDF works.

I need to understand all of this so that I don't do something in the
Xegl server that will hurt text display performance. I might even be
able to figure out a way to help speed things up.

-- 
Jon Smirl
jonsmirl at gmail.com