Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!sun-barr!decwrl!gnomee.pa.dec.com!kent
From: kent@gnomee.pa.dec.com (Christopher A. Kent)
Newsgroups: comp.windows.x
Subject: Re: Porting X Applications to the DECstation 3100
Message-ID: <1718@bacchus.dec.com>
Date: 22 Aug 89 23:15:31 GMT
References: <2486@husc6.harvard.edu> <initial> <post> <10155@csli.Stanford.EDU>
Sender: news@decwrl.dec.com
Distribution: usa
Lines: 24

In article <2486@husc6.harvard.edu>  kochhar@endor.harvard.edu (Sandeep Kochhar) writes:

>I had a problem with the DEC3100 cfb that sounds similar; essentially
>the GXxor function wasn't working right (though it worked fine on a
>Sun B/w and color);   I didn't look at it too long since I discovered
>that a hack worked: switching the background and foreground colors
>in my GC.

If you were trying to invert foreground and background using GXxor, it won't *ever* work. To quote from a message from RWS, "This is one of the most common X programming errors." He went on to say

If you have two values
(pixelA, pixelB) that you want to swap between, you should either:

    set the GC foreground to (pixelA ^ pixelB) and function to GXxor
or
    set the GC planemask to (pixelA ^ pixelB) and function to GXinvert

Otherwise, your code will fail on some sex of monochrome display or some
variation of color.

Now, if you have a bona fide example of GXxor not working on a DS3100, send me a (small) sample program that demonstrates it and I'll make sure it gets to the right person.

Chris Kent	Western Software Laboratory	Digital Equipment Corporation
kent@decwrl.dec.com	decwrl!kent			(415) 853-6639