Re: Pixmap theme, caching and gnome-pixmaps

James Henstridge <> writes:

> I think there is another way to fix this problem which doesn't involve the
> pixmap copying overhead.  Basically free_pixmap_and_mask in gnome-pixmap.c
> is wrong.
> According to the imlib documentation, to free a pixmap that has been
> created by imlib, you call the following function:
>   void gdk_imlib_free_pixmap(GdkPixmap *pixmap);
> This function will also free the associated mask, and take the imlib cache
> into account.
> In free_pixmap_and_mask, it uses gdk_pixmap_unref directly, which is what
> is stuffing up imlib's internal structures.  The correct implementation of
> free_pixmap_and_mask should be:
> static void
> free_pixmap_and_mask (GnomePixmap *gpixmap)
> {
>         g_return_if_fail (gpixmap != NULL);
>         g_return_if_fail (GNOME_IS_PIXMAP (gpixmap));
>         if (gpixmap->pixmap) {
>                 gdk_imlib_free_pixmap (gpixmap->pixmap);
>                 gpixmap->pixmap = NULL;
>                 gpixmap->mask = NULL;
>         }
> }
> I have not tested this, but if it doesn't work correctly, then it would be
> an imlib problem.

Well, the problem is, that as soon as you destroy the 
imlib image with gdk_imlib_destroy_image(), the pixmap
and mask are fair game for destruction.

_If_ there was an explicit gdk_imlib_ref_pixmap() call,
then you could use that, destroy the image, and I think
you'd be OK. 

But there isn't. It might work to do:

 	gpixmap->pixmap = gdk_imlib_move_image (im);
	gpixmap->mask = gdk_imlib_move_mask (im);

	if (destroy) {
                GdkPixmap *p1, *p2;
                _gdk_imlib_find_pixmap (im, width, height, &p1, &p2);
		gdk_imlib_destroy_image (im);

To fake the refcount... that's pretty gross, though.

The other alternative would be to keep the imlib image stored
around in the GnomePixmap until the free_pixmap_and_mask()


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