jjt@ohdake.uta.fi (Jyrki Tuomi) (05/10/91)
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