Around 14 o'clock on Sep 3, David Turner wrote:
> 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.
Thanks a bunch; I've read through the FreeType sources and even then the
issues you raise weren't entirely clear.
> regarding libXft:
> - the FT_Face objects are stored as reference-counted
> singletons. they are only destroyed when all
> corresponding XftFont objects have been "closed".
To make things clear to the rest of the list, Xft shares a single FT_Face
object among all XftFonts that use it; that typically means you've only got
one FT_Face for all sizes in use.
> - 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..
This may seem like an opportunity for optimization, however most
applications never render all of the glyphs in a font making this moot.
> regarding Pango:
>
> 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..
Always good to avoid throwing work away; it may be that Gtk+ applications
commonly re-use fonts without holding a reference across the gap.
> 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"..)
The question arises as to the cost of creating/destroying FT_Face objects.
If that's very expensive, we'll be spending a lot of unnecessary time if
this cache isn't well tuned. It needs to be adaptive to allow the number
of FT_Faces to match the application's working set; that will be
complicated.
> 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.
Closing the XftFont will also discard any rendered glyphs and metrics;
this means that each time Pango re-uses a font that has been ejected from
the cache, Xft will rerender all of the glyphs.
> 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"
This seems like the only reasonable place for this fix; Xft can separately
manage the pool of available FT_Face objects and server-resident glyphs so
that memory on both sides of the wire can be conserved.
I think the only change to the Xft API will be a pair of functions that
acquire/release the FT_Face object related to a particular XftFont.
Alternatively, we could simply use a pair of macros which locked/released
the FT_Face field in the XftFontStruct. This would preserve some level of
source compatibility while allowing applications to silently fail, which
seems like a bad idea.
We might also consider "fixing" Pango to eliminate the remaining Xft
overhead for disused fonts, we can analyse the memory usage after Xft has
been fixed.
> > 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.
What I meant was that Xft shouldn't wrap all of the existing FreeType
functions, rather it should provide access to the underlying FreeType
objects and let the application use the FreeType API. The change outlined
meets this requirement; applications continue to touch FreeType directly,
however they must interact with Xft to get the FreeType objects.
> - 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.
I'm not convinced that we need a libray abstraction here; it's no mystery
that FreeType fonts live in files on the disk. One library API that
already exists in Xft is the ability to add an arbitrary file or directory
to the set of available fonts. This means that applications can add their
own fonts to the system on the fly and Xft will adjust future font matches
to take them into account.
One additional thing that Xft could do is accept an existing FT_Face
object and turn that into an XftFont; that's easy to do with a slight
restructuring of the existing code.
> - 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..
Are there version numbers in the font files themselves? As to the glyph
sets, I'm planning on caching the set of available glyphs for each face so
that applications will be able to match fonts based on the set of
available glyphs. It seems like this is in the purview of the font
configuration mechanism.
> 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..
I'll go take a look and see what they've got.
> 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 read over the information on the microsoft page, and have reviewed
patent 6239783. As their entire focus is on generating images of the
correct color, and my entire focus is on generating images with the
correct translucency, I think my technique is distinct. This is born out
in their implementation which requires both the foreground and background
colors be presented to the glyph rasterization subsystem. Xft doesn't need
either; the data are independent of both allowing text to be painted with
a pattern over a patterned background, something which ClearType cannot do.
Here's a quote from claim 1:
"generating a separate luminous intensity value for each pixel sub-component
as opposed to each full pixel, the separate luminous intensity value for
each sub-component being based on the different set of one or more samples
mapped thereto; and"
Pointers to additional patents are welcome, along with any discussion of
their claims.
I should probably file for a patent on my technique; it's at least as
patentable as theirs.
> > > 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 ??
A reference to Lewis Carroll's "Through the Looking Glass".
[EMAIL PROTECTED] XFree86 Core Team SuSE, Inc.
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
