Article View: comp.windows.x
Article #24829GXxor and GXnor (Summary)
From: Marc Gemis
Date: Tue, 12 Jan 1993 07:34
Date: Tue, 12 Jan 1993 07:34
122 lines
5655 bytes
5655 bytes
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
--------------------------------------------------------------------------
Technical Details
Message-ID:
<MAKKE.93Jan12083441@wins.uia.ac.be>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!ub4b!reks.uia.ac.be!newsShow Full Headers
Complete Article Headers
Newsgroups: comp.windows.x Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!ub4b!reks.uia.ac.be!news From: makke@wins.uia.ac.be (Marc Gemis) Subject: GXxor and GXnor (Summary) Message-ID: <MAKKE.93Jan12083441@wins.uia.ac.be> Sender: news@reks.uia.ac.be (USENET News System) Organization: /home/wins/inf/makke/.organization Distribution: comp Date: Tue, 12 Jan 1993 07:34:41 GMT Lines: 123