[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
Objologist
Light travels faster than sound. This is why some people appear bright  
until you hear them speak...






More information about the cairo mailing list