🚀 go-pugleaf

I am experiencing some peculiar behaviour using GpiWCBitBlt.  Either I have
understood some ROP-operations completely wrong or GpiWCBitBlt doesn't work
correctly for me.  This is what I am attempting to do.  I have a bitmap, e.g.
of a diamond-shape figure.  A rough sketch of the bitmap:

			--------
			|  /\  |
			| /  \ |
			|/    \|
			|\    /|
			| \  / |
			|  \/  |
			--------

The horizontal and vertical lines are not part of the bitmap, they are just
to illustrate the bitmap rectangle.  The diamond-shape has black borders and
is filled with some color (e.g. blue).  Background of the bitmap is white
(as is the window background).  I wish to paint a new bitmap in the window
so that the corners of the bitmap (which are of the background color) do not
"overpaint" what is already on the screen.  Clearly ROP_SRCCOPY is no good,
as then GpiWCBitBlt will copy all bitmap bits to screen, like this:

			/\
		       /  \
		      /    \ (already on screen)
		      \    /
		    /\    / (lower left corner is "cut")
		   /  \ \/
                  /    \
		  \    /
		   \  / (a new bitmap drawn using ROP_SRCCOPY)
		    \/

Pretty basic, eh?  To me, GpiWCBitBlt with ROP_SRCPAINT seems like to right
way to do the job.  But when I change the ROP_SRCCOPY to ROP_SRCPAINT no
output at all will be written on the screen!  This really can't be right...

Has anyone else come across this kind of behaviour?  I would appreciate
any replies and/or confirmation of this or the opposite (i.e. expected)
behaviour of ROP_SRCPAINT.  My setup is IBM OS/2 1.2 EE and MS PM 1.2
Toolkit, PS/2-70 with color VGA.

	Jyrki

--
Jyrki Tuomi                    |  "The only bright side to this [global envi-
                               |  ronment pollution] is that eventually there
Internet: jjt@cs.uta.fi        |  may not be a piece of the planet worth
UUCP    : jjt@utacs.uucp       |  fighting over"  --  Calvin