You'd probably looking for a copy-constructor for the pixbuf for cloning... Also, the pixel-copying would be handled by a single method call on the pixbuf.
As for adding a click to the reference count, if it works, would probably be the best way to go (I admit I don't quite understand the implications... I'm quite used to java you see...) Jonathan On 9/11/07, Tom Trebisky <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 11, 2007 at 10:29:45PM +0200, Jonathan Winterflood wrote: > > Hi, > > > > You could clone the > > pixbuf, or create a new one the same size and blit the content of the > > soon-to-be recycled one into the new one before unref'ing the loader > > Cloning sounds like just what I want to do, I'll go see if I can find > a generic object cloning routine - or I will just live with whatever > extra baggage the pixbuf_loader leaves around. The ideal thing, so > as to avoid copying oodles of pixels, would be to tick the reference > count for the pixbuf the loader has so that it will stick around > when I unref the loader. > > Thanks! > > > Jonathan > > > > On 9/11/07, Tom Trebisky <[EMAIL PROTECTED]> wrote: > > > > > > Following this thread, I decided it would be wise to avoid this kind > > > of leak since my application uses hundreds of loaders to load > > > hundreds of pixbufs, so I made my code look like: > > > > > > pixbuf_p = gdk_pixbuf_loader_get_pixbuf(my_loader); > > > g_object_unref ( my_loader); > > > > > > add_to_my_list ( pixbuf_p ); > > > > > > However, this apparently frees up the pixbuf as well, and everything > goes > > > to hell in a handbasket as pixbuf_p is now a reference to some piece > > > of recycled memory or something like that. How does one free up the > > > loader but retain the pixbuf ? > > > > > > Tom > > > > > > -- > > > Tom Trebisky > > > MMT Observatory > > > University of Arizona -- Tucson > > > [EMAIL PROTECTED] > > > _______________________________________________ > > > gtk-app-devel-list mailing list > > > gtk-app-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > > > > > > > > > -- > > <Morpheus> linux, c'est une question de VI ou de MORE > > -- > Tom Trebisky > MMT Observatory > University of Arizona -- Tucson > [EMAIL PROTECTED] > -- <Morpheus> linux, c'est une question de VI ou de MORE _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
