Re: [Bug 111028] Dealing with reference cycles in GObject

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-04-24 at 12:51, J. Ali Harlow wrote:
> On 2003.04.24 17:44 Havoc Pennington wrote:
> > On Thu, Apr 24, 2003 at 04:20:01PM +0100, J. Ali Harlow wrote: 
> > > 3. Change gdk_drawable_get_image() to always return a copy of the
> > >    image. This is much easier but would reduce efficiency.
> > 
> > Maybe this is right; otherwise the win32 port has different semantics
> > from the X port. Maybe it could return a "shallow copy" of the image
> > but it seems like it needs to return a copy...
> 
> There's much to be said for this. I haven't actually tested it but
> my reading of the current code is that if you use gdk_drawable_get_image()
> and then modify the image you'll be changing the pixmap at the same
> time. As I say, this makes things much more efficient but should
> really be documented if it is to be kept as is.

Hmm, my initial thought was "no, you can't do that optimization,
the caller is allowed to modify the image", but looking at the docs 
for gdk_drawable_get_image(), they say:

 * If the X server or other windowing system backend is on the local
 * machine, this function may use shared memory to avoid copying
 * the image data.

Which strongly implies that you might or might not get the 
actual data, and thus shouldn't count on being able to modify
it. So, I think the optimization is fine, though it isn't
100% clear to me that it is a good idea, since it is going
to kill the ability of the Win32 port to do *any* hardware
optimization of drawing.

That being said, I simply don't see the code in gdk/win32 to
do this. It looks like to me that drawable_get_image() does
always make a copy on win32.

> > However, I'm not sure I understand the refcount cycle that you're
> > seeing (i.e. what are all the links in the cycle?)
> 
> Maybe that's because it's in my head :-)
> 
> The current situation is that the reference counting is simply
> wrong which causes the bug I reported. The obvious way to fix
> it might be to count all references. However doing so causes
> the cycle I describe.
> 
> Ie., user calls gdk_pixmap_new() which creates a new GdkPixmap
> with a floating reference and then calls
> _gdk_win32_setup_pixmap_image() to create a new GdkImage with
> a floating reference. _gdk_win32_setup_pixmap_image() creates
> a reference to the associated GdkPixmap so does a g_object_ref
> followed by a gtk_object_sink.

I don't see any reference. Are you maybe looking at something
other than the current gtk2 branch code?

>  Finally gdk_pixmap_new() does a g_object_ref/gtk_object_sink on 
>  the new GdkImage.
> 
> Net result: GdkPixmap returned to the user has reference count
> of 1 and the associated GdkImage also has a reference count
> of 1. This cycle will prevent the two objects ever being finalized
> unless somebody calls g_object_dispose() and the dispose()
> function was implemented.
> 
> At least, that's how I worked it out in my head. It could be
> a load of rubbish. I'm very much a GObject beginner.

Well, it sounds a little suspicious, since there are no floating
references at the GDK layer :-)

I must admit of bit of confusion trying to correlate your
mail with the current code.

Regards,
                                          Owen