Bug in gdkdrawable-x11.c?

[Bernhard Herzog <herzog online de>]

In gdk/x11/gdkdrawable-x11.c there's:

gdk_x11_draw_drawable (GdkDrawable *drawable,
		       GdkGC       *gc,
		       GdkPixmap   *src,
		       gint         xsrc,
		       gint         ysrc,
		       gint         xdest,
		       gint         ydest,
		       gint         width,
		       gint         height)
{
  int src_depth = gdk_drawable_get_depth (src);
  int dest_depth = gdk_drawable_get_depth (drawable);

  if (src_depth == 1)
    {
      XCopyArea (GDK_DRAWABLE_XDISPLAY (drawable),
		 GDK_DRAWABLE_XID (src),
		 GDK_DRAWABLE_XID (drawable),
		 GDK_GC_GET_XGC (gc),
		 xsrc, ysrc,
		 width, height,
		 xdest, ydest);
    }

Shouldn't this be XCopyPlane? XCopyArea requires two drawables of the
same depth.

Furthermore, assuming XCopyPlane would be indeed correct, is it really a
good idea to mix XCopyPlane and XCopyArea in one function? 

The problem I see is that there's an important difference between
XCopyPlane and XCopyArea. XCopyArea copies the bits of the region as is,
the only parameters of the GC that influences it are the clip mask and
function (and a few more esoteric ones like subwindow_mode and
graphics_exposures) XCopyPlane is also affected by foreground and
background color.

Being able to distinguish between XCopyPlane and XCopyArea would be
important if you want to copy a bitmap (1 bit pixmap) into another
bitmap. OK, you could 'fake' the XCopyArea with an XCopyPlane for a
bitmap if you take care to use a gc with foreground 1 and background 0.

That last sentence reminds me of a quirk in gdk's design. The only way
to specify the foreground and background colors of a GC is through a
GdkColor which at least conceptionally is always an RGB triple. For a
bitmap this makes absolutely no sense, the only possible colors are 1
and 0, and even on a color display you sometimes want to specify exactly
which bits should be influenced, e.g. if function is GDK_XOR.

Now, I can work around this by creating a GdkColor with bogus rgb values
and a specific pixel value, but that's ugly. How about adding a
gdk_gc_set_foreground_bits function (and an equivalent for the
background)? This function would take a gulong as parameter and would
use that as the pixel value.


-- 
Bernhard Herzog   | Sketch, a drawing program for Unix
herzog@online.de  | http://sketch.sourceforge.net/