freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] Re: Reference count in FreeType2


From: Behdad Esfahbod
Subject: [ft-devel] Re: Reference count in FreeType2
Date: Mon, 15 Mar 2010 23:58:22 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

On 03/15/2010 11:43 PM, address@hidden wrote:

> However, yet I've not figured out the detailed usecase for
> reference counter of FreeType2 (so I cannot write short testing
> code), thus I cannot start working just now. If you know any
> softwares showing the problem caused by the lack of reference
> counter, please let me know. Should I compare older & newer
> cairo?

Use case is very simple:  with the FreeType stack, all of hb_face_t,
PangoFont, and cairo_scaled_font_t all can use keeping a pointer to an
FT_Face.  But alas, one cannot do that safely since you never know when the
face is going away.  So this is how they deal with it currently:

  - Cairo: For cairo-created faces, it adds a ref-counted wrapper around it
itself.  For user-provided faces, it's user's responsibility to make sure the
FT_Face is not finalized before the cairo_face_t (which is refcounted).

  - harfbuzz: It's user's responsibility to make sure the face is available.

  - Pango: Lacking refcounts is not the only problem FT_Face.  The other is
that it also includes a FT_Size and a glyph slot in it.  Pango currently uses
a lock/unlock scheme (exported by Cairo) to get exclusive access to the
FT_Face and release it every time the FT_Face is needed.

If there was refcounts in FreeType, harfbuzz could increment the refcount on
the FT_Face it keeps a pointer to.  Cairo could also increase the refcount of
user-provided faces such that the face wouldn't die after FT_Done_Face() was
called but cairo still has a pointer to it.

In general, to be binding friendly, and programmer friendly, any library
should provide refcounting to make it easier to tie object lifecycles
together.  Try writing a Python binding for FreeType to see how impossible
that is.

FreeType currently has a generic-data pointer with a destroy callback and both
Pango and harfbuzz use that slot to cache some stuff on the face, and they
race over the use of the slot of course.  Attaching user data to objects is
another useful feature of object systems.  Both glib and cairo provide that
(but not harfbuzz yet).  That's also very useful for bindings.

behdad

> Regards,
> mpsuzuki
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]