Hello,
Now that I have taken the time to read the complete sources
of both libXft and Pango, I'd like to make a few points
regarding their design in order to improve them, since it
seems that both use much more memory than they really need.
I have not looked at the Qt code, but it may exhibit the same
problems (and be cured in a similar way).
Both libraries seem to ignore that the objects created by
FreeType are _not_ lightweight. Each FT_Face contains a
significant amount of information regarding each font:
- each FT_Face corresponds to a complete memory-mapped
file on Unix builds of the library (or a FILE* on
most other systems).
- for TrueType fonts, with the bytecode interpreter
enabled, FT_Face objects for fonts like Arial or
Times New Roman can easily take 30 to 50 Kb of
memory.
- for Postscript fonts, FreeType uncompresses and
uncrypts the glyph charstrings to store them in
memory, in order to render them much more
quickly. This can take from 10 to 30 Kb per font
too.
in short, a FT_Face is not a "logical font" and should be
treated as a rather heavy weight object.. I suppose that
this could have been made more clear from the FreeType
documentation, since it's only really exposed in the
caching sub-system's docs..
regarding libXft:
- the library uses FT_Face objects to extract glyph
images and metrics, which are then sent to and
cached within the server on demand.
- it associates one live "FT_Face" per opened "XftFont"
object (that doesn't correspond to a core X11 font).
- the FT_Face objects are stored as reference-counted
singletons. they are only destroyed when all
corresponding XftFont objects have been "closed".
- if an application keeps a XftFont object opened,
its FT_Face will still be alive, even if all its
glyphs have been extracted/cached already..
regarding Pango:
- Pango uses the file "pangoxft-fontmap.c" to retrieve
the list of installed fonts from libXft. This source
file contains a _persistent_ cache of XftFont objects
this means that once Pango has matched a font description
into a XftFont object, the latter will remain open until
the application closes, and hence the equivalent FT_Face
objects..
- note that the file "pangoft2-fontmap.c" has the exact
same "persistent cache" problem (it uses FT_Face objects
directly, instead of XftFont ones..).
I thus suspect that GdkEmbedded has the same problem..
As a consequence, a typical application using the current versions
of Pango and libXft will simple eat more and more memory as it
displays text with more fonts..
Finally, don't forget that this memory footprint is duplicated
for _all_ applications, since Pango and libXft are simple
libraries.
Most of this footprint could be avoided if one additional level of
indirection was used to access the FT_Face objects through a
_real_ cache (that would limit the number of opened FT_Face
objects), and using slightly different semantics to access
them (e.g. "acquire_ft_face"/"release_ft_face"..)
That's not really difficult to implement, and there are several
ways to do this:
A - only "fix" the Pango cache(s), and leave libXft as it
currently is. One would probably take a look at the Qt
source code too to see if the same "feature" crept in.
B - "fix" the "libXft" code by changing "XftFreeType.h" and
internals. This would break compatibility (but there
aren't that many projects using this header file for
now), but provide XftFont objects that would be true
"logical fonts"
Each solution works. Even though I consider B to be better, I
could understand if Keith disagreed :-)
> Attempting to build yet another font abstraction on top of FreeType seemed
> ridiculous.
>
Allow me to disagree. the objects that FreeType provides are rather
heavy-weight and do not correspond to the "logical fonts" that typical
application developers use to display text.
And we've already discussed about certain font-metadata that are not
included in the font, and should better be stored in a persistent
database rather than re-generated each time you open a new FT_Face
or XftFont..
(no, you can't "just fix FreeType" for certain things..)
> > - how to install new fonts (allowing applications to
> > install temporary embedded fonts for their own use),
> > how to manage system + user font lists, etc..
>
> I don't see why this is more complicated than a shared configuration file
> that describes where fonts are to be found. Xft augments this with
> per-user configuration allowing additional directories to be added.
>
Two things:
- providing a programmatic API to install new fonts is important
to avoid the mess called font installation script shells, and
to abstract the way the system really stores the files.
An application should be able to install a new font to the
system (if he has the right to do it), to the user directory,
or for its own use only.
this last feature is _extremely_ important for font embedding
which I consider a major feature of any modern graphics system.
- some really interesting issues arise when you need to deal with
duplicate fonts, font files with the same name but of different
versions or with different glyph sets / charmaps, etc..
and I'm not talking about font substitution problems :-)
If you intend to deal with these problems within libXft, have a
look at the Gnome-Print code, they've done some good work in
this direction..
> To eliminate the X dependencies for non-graphical applications, Xft must
> not be the place where font configuration is done. I think the basic job
> that Xft does for locating fonts is reasonable and might be a good
> starting point for discussion.
>
Agreed :o)
> > - move the LCD filtering to FT2 (well, well, optional)
>
> That belongs in Xft -- it depends intimately on the physical
> characteristics of the output device. FreeType already provides more than
> adequate APIs for doing this easily.
>
The only reason why I haven't put LCD filtering within
the FreeType rasterizer yet is mainly because I hadn't the time to
read the ClearType patents in details. And I'm extremely cautious
about avoiding new issues in this field ;-)
Have you checked the patents to see if your code infringed them ??
I believe that GdkEmbedded, QtEmbedded, Berlin, DirectFB and a few
other projects would be interested in the ability to render
LCD-filtered glyph images too..
Also, the physical characteristics of the output device can be simply
asked to the user through a simple dialog. That's what Microsoft Reader
and Acrobat 5.0 do, even on PDAs, and it's pretty simple..
> > Gee, am I dreaming or not ? ;-)
>
> No, you're just a part of the Red King's dream...
>
Not being a native english speaker, I do not understand your answer !?
Could someone enligthen me ??
Best Regards,
- David Turner
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
