Re: GdkPixmap bugs

[Owen Taylor <otaylor redhat com>]

Ron Steinke <rsteinke w-link net> writes:

> > From: Owen Taylor <otaylor redhat com>
> >
> > And the colormap handling in gdk_pixmap_new() needs special-casing 
> > for the case where the depth of the window is not the
> > same as the depth of the new pixmap. In the case where
> > depth == 1, we may be able to supply a proper default colormap,
> 
> How would you go about creating a GdkVisual of depth 1?

Thinking about it before ... my comment is really nonsensical.

The right thing to do when creating a pixmap where the depth of the
pixmap doesn't match the depth of the supplied window (or the root
window, if window is passed in as NULL), is always to leave the
colormap unset.


You can't actual "create" a visual - the set of visuals is fixed.

X's model is actually a little bizarre - you can create pixmaps of
depths for which there is no corresponding visual and colormap. (The
list of allowed depths for a screen can be retrieved with
XListDepths(), something not exposed through GTK+)

The uses of this are:

 - For traditional X rendering, depth 1 bitmaps for masks,
   XCopyPlane, etc.

 - For the Xrender extensions, alpha masks, 24 bit images offscreen
   images, etc.

However, the bits in such a pixmaps are completely uninterpreted as
far as traditional X rendering is concerned. (Xrender allows
association of an interpretation with a pixmap using a "picture"
object.)

GDK would much rather that it knew the interpretation of the bits in a
pixmap ... otherwise, calls such as gdk_draw_rgb_image() have nothing
to go on. That's why we have gdk_drawable_set_colormap(), and why
gdk_pixmap_new() copies the colormap from the drawable passed in to
the pixmap when possible.

However, if there _is_ no such interpretation (and there typically is
no such interpretation for a bitmap), it doesn't make sense to make
something up.

Regards,
                                        Owen