ceb@csli.Stanford.EDU (Charles Buckley) (08/21/89)
I am trying to port an essentially black-and-white application (which nonetheless worked on a Sun 8-bit color server) to an 8-bit DECstation 3100 server, and am having many problems. I've managed to pin them down server specific things, e. g.: 1. I can't create a 1-bit deep top-level InputOutput window when the depth of the root screen is 8, although I should be able to. 2. When I go around this by making all of my windows 8 bits deep, but copy into them from 1-bit deep pixmaps using CopyPlane, the result I get is totally wrong (old window pixel 1: pixmap pixel 1: plane arg to CopyPlane 1, GC plane mask FFFFFFFF, result window pixel 0). Is there something obvious I am missing here? This server (Xcfb) is brand new - does anyone know how reliable it is? Things seem to run on it, but so did my application elsewhere up to now. I would be glad to contact DEC about this, but it's a big organization, and I don't want to again get into shouting down a -30dB SPR pipeline . . . Knowledgeable people read this newsgroup - do you think you might provide a pointer? Thanks in advance.
rws@EXPO.LCS.MIT.EDU (08/21/89)
1. I can't create a 1-bit deep top-level InputOutput window when the
depth of the root screen is 8, although I should be able to.
Why do you think you should be able to?
2. When I go around this by making all of my windows 8 bits
deep, but copy into them from 1-bit deep pixmaps using CopyPlane, the
result I get is totally wrong (old window pixel 1: pixmap pixel 1: plane arg
to CopyPlane 1, GC plane mask FFFFFFFF, result window pixel 0).
CopyPlane in this mode depends on the foreground/background values in the GC.
You don't say what they are.kochhar@endor.harvard.edu (Sandeep Kochhar) (08/22/89)
In article <10155@csli.Stanford.EDU> ceb@csli.Stanford.EDU (Charles Buckley) writes: >I am trying to port an essentially black-and-white application (which >nonetheless worked on a Sun 8-bit color server) to an 8-bit >DECstation 3100 server, and am having many problems. > >I've managed to pin them down server specific things, e. g.: >1. I can't create a 1-bit deep top-level InputOutput window when the > depth of the root screen is 8, although I should be able to. >2. When I go around this by making all of my windows 8 bits > deep, but copy into them from 1-bit deep pixmaps using CopyPlane, the > result I get is totally wrong (old window pixel 1: pixmap pixel 1: plane arg > to CopyPlane 1, GC plane mask FFFFFFFF, result window pixel 0). 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. Sandeep Kochhar (617) 495-9515 mail: kochhar@harvard.harvard.edu Harvard University kochhar@harvard.csnet 33 Oxford st, kochhar@harvard.uucp Cambridge, Ma 02138 kochhar@harvard.bitnet "If you didn't get this message, please let me know."
kent@gnomee.pa.dec.com (Christopher A. Kent) (08/23/89)
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