Re: Xft version 2 patches for gtk+ and pango

[Owen Taylor <otaylor redhat com>]

Keith Packard <keithp keithp com> writes:

> Around 15 o'clock on Feb 19, Owen Taylor wrote:
> 
> > I'm very eager to look at these patches. Unfortunately, with the
> > GTK+-2.0.0 release 1 week and change off, I'll have to hold my
> > horses for a bit.
> 
> That's fine; this patch is required to build against current XFree86 CVS, 
> but obviously that can wait until after 2.0.0 is out the door; I can 
> regenerate the patch once 2.0.0 is stable for people interested in using 
> current X bits.
> 
> > -FT_Face       pango_xft_font_get_face          (PangoFont *font);
> > +FT_Face       pango_xft_font_lock_face         (PangoFont *font);
> > +void	      pango_xft_font_unlock_face       (PangoFont *font);
> > 
> > Is in a portion of the Pango API protected as unstable, and even
> > if we need to maintain compatibility, we can provide a compatibility
> > pango_xft_font_get_face() that locks the font and leaves it lock.
> 
> This is the most serious infraction by the current API -- leaving the face 
> locked means that the underlying freetype object can never be freed, not 
> even when the font is closed.  

Well, Pango can keep track and unlock when the PangoFont goes out of use;
which should work reasonably well. I don't think any changes to Xft
are necessary to get not-entirely-broken behavior.

> I'm willing to fix that part if you're 
> willing to add the unlock/lock APIs and make sure no-one "real" is using 
> the 'get' API.  It would be really useful if Pango 1.0 exposed the lock/
> unlock API, even if the rest of the library is left unchanaged, and even 
> if the library still builds against Xft 1.0.

Because this is in the marked-unstable portion, we can add to the API in
1.0.x and use it from the modules. Even in the marked-unstable portion
though, I'd rather avoid removing API calls.

Regards,
                                        Owen