As a discussion on gtk-vnc-devel showed, the problem is actually not in
gtkglext but in GTK itself. It's already fixed upstream:
http://svn.gnome.org/viewvc/gtk%2B?view=revision&sortby=date&revision=19969
Here's the explanation from the patch author:
On Thu, Apr 24, 2008 at 12:19:21PM +0100, Daniel P. Berrange wrote:
> That changeset is definitely the fix - the problem was that GtkGLExt loads
> a GdkColourmap object based on the global colormap ID stored in a property
> on the root window. When the GtkGlExt config object is unref, it unrefs
> the colormap, and this causes Gtk to destroy the global shared colormap.
> The fix stops Gtk from destroying foreign shared colormaps.
I've also attached the patch to this mail. Please apply.
Cheers,
-- Guido
--- trunk/gdk/x11/gdkcolor-x11.c 2008/04/03 01:23:41 19968
+++ trunk/gdk/x11/gdkcolor-x11.c 2008/04/03 05:08:05 19969
@@ -46,7 +46,7 @@
GdkColorInfo *info;
time_t last_sync_time;
- guint foreign : 1;
+ gboolean foreign;
};
#define GDK_COLORMAP_PRIVATE_DATA(cmap) ((GdkColormapPrivateX11 *) GDK_COLORMAP (cmap)->windowing_data)
@@ -107,7 +107,7 @@
gdk_colormap_remove (colormap);
- if (!private->screen->closed)
+ if (!private->screen->closed && !private->foreign)
XFreeColormap (GDK_SCREEN_XDISPLAY (private->screen), private->xcolormap);
if (private->hash)
@@ -1292,6 +1292,7 @@
private->screen = screen;
private->xcolormap = xcolormap;
private->private_val = FALSE;
+ private->foreign = TRUE;
colormap->size = visual->colormap_size;
