[cairo] UserFontFace vs FtFontFace management (cairomm)

[Jonathon Jongsma]

Murray Cumming wrote:
> On Mon, 2008-12-08 at 09:11 -0600, Jonathon Jongsma wrote:
>> Actually, the concept is much simpler -- RefPtr no longer has any reference count. 
>> There's basically two parts to the change.
>>
>> RefPtr:
>> RefPtr<T> would no longer have any direct role in deleting the C++ wrapper object. It only 
>> calls T::reference() on copying (which should result in cairo_*_reference() being called), 
>> and T::unreference() on destruction (which should result in a call to cairo_*_destroy()).
>>
>> Wrapped Objects:
>> In order for the previous RefPtr changes to work, the wrapper classes must be changed 
>> slightly.  When a wrapper object is constructed, it must install itself in the user_data 
>> of the underlying object.  Then when the C object's reference count reaches zero, the 
>> registered user_data destroy function will be called, which will result in the wrapper 
>> object being deleted.  This allows the wrapper function to live on after our last RefPtr 
>> has died if there is an internal reference held on the object somewhere.
> 
> That sounds useful now that we are using sigc callback slots, which
> would otherwise be disconnected when the instance is deleted. 

It's not only useful for that, it's also useful for various get_* functions.  For example, 
something like Context::get_font_face() could return the *exact same* C++ wrapper object 
that we used when we set the font face rather than creating a new one to wrap the 
underlying object.

For example, right now
RefPtr<FontFace> foo = ...;
cr->set_font_face(foo);
RefPtr<FontFace> bar = cr->get_font_face();

foo and bar are two totally different C++ objects that happen to wrap the same C object. 
This isn't a big deal if the wrapper object is very thin and has no state (data) of its 
own, but it could still cause some confusion to application developers.  If we stored the 
wrapper object in the user_data of the C object, we could actually return the exactly same 
wrapper in this case.

> For now we
 > should probably document that those slots will only be valid as long as
 > the C++ instance is alive.

yeah, that's definitely an option for the short term.

I'm a little scared by all the cleverness that we might need to add to
> allow various things to be destroyed in various sequences in various
> ways, but this should at least be simpler than it was for gtkmm. This
> should be in bugzilla at least.
> 
> We'd need some way to make the new code work with old versions of the
> RefPtr that are compiled into already-built applications.

This deals with very basic memory management issues.  I don't really see any way to mix 
and match two very different ways to manage the lifetime of the same object.

> Alternatively, we could wait for the gtkmm ABI break that will be forced
> upon us by GTK+ 3.0, if that actually happens as they plan.

Yeah, I guess this would be the most prudent course of action.

-- 
jonner