Obviously I don't speak formally for Clutter, but... What you say has been my experience.
Also, keep in mind that what they are doing is more like ownership, like Emmanuele says, and less like regular refcounting. When a ClutterGroup runs out of references and is disposed, it will actually go through and destroy the actors that are parented to it, whether they have references remaining or not. So you shouldn't plan to have objects referenced from multiple places and yet have them in a container that gets destroyed. It's worth reading through the clutter-group.c and clutter-container.c dispose code, just to get a feel for what they're doing. --- On Sun, 3/8/09, Michael Boccara <[email protected]> wrote: > From: Michael Boccara <[email protected]> > Subject: Re: [clutter] About clutter_actor_set_parent and reference counting > To: "Emmanuele Bassi" <[email protected]> > Cc: [email protected] > Date: Sunday, March 8, 2009, 4:03 AM > I understand better now. > > Having actors hold a ref count of its parent would create a > circular > reference which would cause actors to never be disposed. > > The rule of thumb in clutter is that ref counting is always > done in the > descending direction of the scene graph. > > Did I get it right ? > > > > Michael > > > > Michael Boccara wrote: > > > Thanks Emmanuele, > > > > I understand the rationale. > > > > It just goes against my belief in a rule of thumb that the > reference > count of a pointer should always be incremented as soon as > this pointer > is assigned. Although the clutter scene graph should be > seen as a > descending graph only, every actor *does* hold a persistent > pointer to > the parent, and somehow supposes that this pointer is valid > in many > places, while there is no ref mechanism to guarantee such > thing. > > > > Also, relying on clutter_actor_set_parent to increment the > ref count of > self is just not very intuitive. > > > > The chain of references up to the stage could have been > consistently > maintained by reversing the reference counting process of > parenting, > and no parent would be referenced in the stage. In the end > the stage > would have a reference count greater than the total number > of actors in > its scene graph, which is healthy in the same way in my > mind. > > > > Michael > > > > Emmanuele Bassi wrote: > > On Sun, 2009-03-08 at 02:17 0200, Michael Boccara > wrote: > > > Hi, > > Sorry if this is a dumb question, or if it was asked 1000 > times > before. > > In clutter_actor_set_parent, self ref is incremented. > g_object_ref_sink (self); > priv->parent_actor = parent; > But shouldn't it be the parent actor whose reference > should be > incremented ? > > > > no, that would be wrong. > > > > Otherwise, how do you guarantee the validity of the > parent_actor > pointer ? > > > > at some point, an actor must be parented to a Stage -- > which does not > have a parent actor (and that's also why you don't > incremenent the > reference count of the parent). hence, every actor is now > owned by the > stage at the root of the scenegraph. > > the parenting process should not be viewed as > "reference counting > management": that is an implementation detail. > > when you set the parent of an actor you are effectively > saying that the > parent now owns the child; in GObject-land this means that > the parent > takes a reference on the child, and releases is when > unparent() is > called on the child itself. > > ciao, > Emmanuele. > > > > > > -- To unsubscribe send a mail to clutter > [email protected] > > > > > > -- > To unsubscribe send a mail to clutter > [email protected] -- To unsubscribe send a mail to [email protected]
