Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!slxsys!ibmpcug!ctssuk!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re:  XSetFunction with GXxor on Sun3
Message-ID: <5371@acorn.co.uk>
Date: 25 Feb 91 18:31:18 GMT
References: <9102180503.AA22046@lightning.McRCIM.McGill.EDU>
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 26

In article <9102180503.AA22046@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU writes:
[ clear and useful explanation of the common problem with GXxor ]
>
>Thus, when using GXxor, you should set your foreground color to the XOR
>of your "foreground" pixel value and your "background" pixel value.

<<Skip the following if you had trouble with der Mouse's explanation;
  this will just confuse things more>>

Alternatively set the foreground ``colour'' (ie pixel value) to ~0
(that's the *pixel value* with all bits set, not the screen white
pixel!) and set the raster op to GXinvert.  The foreground colour
doesn't matter.

On a well written server this will be handled precisely as GXxor+~0
plane mask+foreground, but on some servers which support a hardware
bit mask or which spot raster ops with no source pixel involvement
it may be more efficient.  On the other hand, on some servers with
special case optimisation of GXxor it may be significantly less
efficient :-(.

In general using GXclear, GXset and GXinvert with a plane mask may be
easier to understand than using GXand, GXor and GXxor with a suitably
synthesised foreground pixel value.

John Bowler (jbowler@acorn.co.uk)