Pixmap theme, caching and gnome-pixmaps




The problems people have been having with *Bad Window*
errors and pixmap themes seem to be occurring because
of mistakes in the way that gnome-pixmap is handling
Imlib images. (Well, actually, they are occurring because
of mistakes in the design of imlib...)

To be specific, gnome-pixmap widget calls 
gdk_imlib_move_pixmap() and gdk_imlib_move_mask(), then
gdk_imlib_destroy_image(). 

If no caching is enabled, then this works pretty
much as expected - the pixmaps and masks are dissociated
from the image and the imlib data structures are cleaned
up.

If caching is enabled, then bad things happen. move_pixmap()
and move_mask() leave the pixmaps in the cache; the
destroy_image() drops the refcount of the pixmaps to 
zero, and when the cache gets full, the pixmaps are
destroyed.

The following patch fixes things up, but is a rather
inefficient, since it puts every pixmap in GNOME through
a extra copy. I'm not really sure how to do this
better - I'll ask Raster about it when he gets back
from Germany. 
                                        Owen

Index: gnome-pixmap.c
===================================================================
RCS file: /cvs/gnome/gnome-libs/libgnomeui/gnome-pixmap.c,v
retrieving revision 1.32
diff -u -r1.32 gnome-pixmap.c
--- gnome-pixmap.c	1999/03/21 09:02:20	1.32
+++ gnome-pixmap.c	1999/03/29 20:23:06
@@ -617,8 +617,8 @@
 	else
 		gdk_imlib_render (im, im->rgb_width, im->rgb_height);
 
-	gpixmap->pixmap = gdk_imlib_move_image (im);
-	gpixmap->mask = gdk_imlib_move_mask (im);
+	gpixmap->pixmap = gdk_imlib_copy_image (im);
+	gpixmap->mask = gdk_imlib_copy_mask (im);
 
 	if (destroy)
 		gdk_imlib_destroy_image (im);



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