[cairo] Fwd: PangAttrShape destroy func firing unexepctedly

Travis Griggs travisgriggs at gmail.com
Wed Sep 8 08:28:47 PDT 2010

And my one other question (apologies for the cross posting if it's  
bad, once upon a time, I was tol I'd probably have as much luck here  
as elsewhere).

> On Sep 7, 2010, at 6:23 PM, Travis Griggs wrote:
>> What My Binding Ended up Looking Like (for now)
>> With Behdad's and Tony's direction, I established a single shape  
>> renderer for any Context I create a binding for in Smalltalk. When  
>> I'm creating the attribute, I do it with the two rectangles, and  
>> with a Block Closure. Block Closures are Smalltalk arbitrary  
>> functions, that close over any current values needed for the  
>> function. So I get both data and behavior all in one, a lot, or a  
>> little. I keep a table on the Smalltalk side, which maps Smalltalk  
>> blocks, to an arbitrary incrementing counter. The index, is what I  
>> stuff in the data of the attribute. So when I get the callback, I  
>> fetch the Smalltalk block associated with the particular  
>> attribute's data key, execute the block with the mapped arguments.  
>> Works pretty well.
> Or maybe it doesn't work so well. It works well as long as I don't  
> try to clean out said table.
> If I do the following pseudo code:
> attList = pango_attr_list_new();
> attribute = pango_attr_shape_new_with_data( rect1, rect2, aNumber,  
> null, aDestoryFunc );
> pango_attr_list_insert( attList, attribute );
> layout = pango_layout_new(context);
> pango_layout_set_attributes( layout, attList );
> pango_cairo_show_layout( cr, layout );
> Something weird happens. aDestroyFunc happens sometime after I do  
> the show_layout. Which is weird (and currently undesirable) to me.  
> I've been grousing around the pango source, haven't seen where it's  
> happening yet. I know that after the show, the attList still has a  
> ref count of 2 (one from me creating it, and the other from the  
> layout), so it's not destroying it there. I must be missing part of  
> the memory management model here, any help much appreciated, trying  
> to get this stuff figured out so I can give glowing reports when  
> talking about binding to it next week at ESUG.

Travis Griggs
Light travels faster than sound. This is why some people appear bright  
until you hear them speak...

More information about the cairo mailing list