Re: Memory problems with gdk_pixbuf



Dnia 07-06-2005, wto o godzinie 13:22 -0300, John Coppens napisał:
The sentence:

     gtk_object_destroy(GTK_OBJECT(img_item));

Does not destroy the pxb item - the ref_count is not changed to 0... I
scanned over the gnomecanvas.c code, but I cannot find any code for
unreferencing the pixbuf... But then I'm not a great programmer and
not faniliar with the gnome insides.

This is correct. Back in GGAD days, it would actually release the
object, however in GObject 2.0 things were changed, and destroy no
longer releases the object, merely calls its destructor. So if you have
any outstanding references, you need to unref them separately for object
to get freed.

I'm confused. The GGAD (GTK+/Gnome Application Development) is the
"official GNOME programming manual" from the developer pages at Gnome. If
this manual is not updated, shouldn't there be a LARGE warning that is
doesn't apply to the 2.x series of things?

GGAD by Havoc Pennington describes GNOME 1.x platform and GTK+ 1.2.
While largely similar, certain fundamental things did change in 2.x, so
it's no longer relevant as it were once. Poor up-to-dateability of
developer pages is known bug, and various people are (or were) trying to
improve things. Filing a bug in bugzilla on this particular misleading
info is not a bad idea.

The successor to GGAD book is The Official GNOME 2 Developer's Guide by
Matthias Warkus, see http://www.nostarch.com/frameset.php?startat=gnome

Is there some document that describes exactly those differences?

Various. Most fundamental changes in GLib/GTK+ platform for example are
covered by FAQ and migration section in API reference documentation.

The 'GNOME Canvas Library Reference Manual' for gnome 2.2 describes how
canvasitems are made ('new') but not how they are destroyed, and what
happens to the objects they own.

Because it's not anything specific to Canvas. Canvas items are normal
GObjects, and as such, are subject to usual lifetime rules. The only
exception here is GtkObject -- subclasses of it behave differently as to
who owns initial reference, using so called "floating reference".
There's documentation on it available on net, although not as gathered
in one place as we could wish -- that's part of the ongoing effort to
improve developer pages I mentioned above.

Cheers

-- 
Maciej Katafiasz <ml mathrick org>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]