From: makke@wins.uia.ac.be (Marc Gemis)
Subject: GXxor and GXnor (Summary)
Organization: /home/wins/inf/makke/.organization
Distribution: comp
Date: Tue, 12 Jan 1993 07:34:41 GMT


In article <MAKKE.93Jan8172333@wins.uia.ac.be> I wrote:
>Hi,
>
>I found the following strange behavior in X11R4, delivered with DG/UX 5.4.1.
>To have xor behavior, (draw on a set pixel means clear that pixel),
>I must use GXnor. On a Sun with X11R5, I'll have to use GXxor.
>My question is: Is this a bug in the DG/UX-port, a bug in X11R4
>and are there any other systems that have the same problem ?
>
>I have a small Motif program to test this. If you want I can send you
>a copy of it.
>
>I'll summarize the responses and post it to the net.
>
>Thanks in advance.
>

I misunderstand the concept of GXxor, as pointed out by Errol Crary
(errolc@tv.tv.tek.com.).

Errol> I would guess from the wording of your news article that the
Errol> answer is that you are not understanding the concept of a pixel
Errol> and of xor in this case.

Errol> First, a pixel is a value that has bits set in different places
Errol> depending upon the color mapping hardware of your system. Only
Errol> in the simplist case- mono screen- does that become a case that
Errol> you can pre-guess.

Errol> For example a White pixel might have a value of 0xffffff while
Errol> a Black pixel might have a value of 0x1.

Errol> Second, there is no concept of set and clear of a pixel in X.
Errol> What are you expecting when you say clear? Does the pixel value
Errol> represent the Background color, or ???. And to set a pixel
Errol> means ???

Errol> This means that the idea of xor is to convert pixel values to a
Errol> known pattern based on the boolean xor operation usually so
Errol> that the pixels may later be converted back to their original
Errol> color. Oliver Jones seems to be the expert on this set of
Errol> operations, and describes them best. I don't see his normal
Errol> response in the FAQ, but I do see one by Flatters and Whaley

Errol> -----------------------------------------------------------
Errol> Subject: 139) Why doesn't GXxor produce mathematically-correct
Errol> color values?

Errol> 	When using GXxor you may expect that drawing with a value of
Errol> black on abackground of black, for example, should produce
Errol> white.  However, the drawing operation does not work on RGB
Errol> values but on colormap indices. The color that the resulting
Errol> colormap index actually points to is undefined and visually
Errol> random unless you have actually filled it in yourself. [On many
Errol> X servers Blackand White often 0/1 or 1/0; programs taking
Errol> advantage of this mathematical coincidence will break.]  If you
Errol> want to be combining colors with GXxor, then you should be
Errol> allocating a number of your own color cells and filling them
Errol> with your chosen pre-computed values.  If you want to use GXxor
Errol> simply to switch between two colors, then you can take the
Errol> shortcut of setting the background color in the GC (graphics
Errol> context) to 0 and the foreground color to a value such that
Errol> when it draws over red, say, the result is blue, and when it
Errol> draws over blue the result is red.  This foreground value is
Errol> itself the XOR of the colormap indices of red and blue.

Errol> [Thanks to Chris Flatters (cflatter@zia.aoc.nrao.EDU) and Ken
Errol> Whaley (whaley@spectre.pa.dec.com), 2/91]
Errol> -------------------------------------------------------------

Errol> Without testing, I think the hint you need is that there are 2
Errol> colors that are of concern-- Present pixel and Desired pixel.
Errol> Create a conversion mask by Mask = Present ^ Desired.  Now, to
Errol> go from the present color use the mask with the GXxor
Errol> operation, and to get back to the current color, use the mask a
Errol> second time with the GXxor operation.

Errol> The only places you are guaranteed the Desired color are the
Errol> pixels that are the Present color. All other pixels will be
Errol> changed, and will revert, but not to the Desired color and the
Errol> Present color.

Errol> I hope this helps. I would guess that DG does not use the same pixel values
Errol> as Sun for the WhitePixel and BlackPixel, and that is where you are getting
Errol> your error. Have you printed the values of these variables on both
Errol> machines??

The solution is to set the mask to Present ^ Desire (see above).

in my code this gives:

 	values.function = GXxor ;
 	values.foreground = BlackPixelOfScreen(XtScreen(wdg)) ^ WhitePixelOfScreen(XtScreen(wdg));


This was also the answer of George Ross (gdmr@dcs.edinburgh.ac.uk).


I would like to thank


dhawes@dcs.qmw.ac.uk
George Ross (gdmr@dcs.edinburgh.ac.uk)
Errol Crary (errolc@tv.tv.tek.co)
Mark Lanzo (gecko!lanzo@uunet.UU.NET)



--



--------------------------------------------------------------------------
Marc Gemis                                   Tel: + 32 (3) 820.24.18
University of Antwerp (UIA)                  Fax: + 32 (3) 820.24.21
Dept. Math. and Comp. Science                Telex 33.646
Universiteitsplein 1                         Email: gemis@uia.ac.be
B-2610 Wilrijk - Antwerpen
BELGIUM
                A dog is for life... not just for Christmas
--------------------------------------------------------------------------

Newsgroups: comp.windows.x