ctr@xpiinc.UUCP (03/16/89)
In a recent message, Peter Galvin notes that on a particular server,
the GXset and GXclear, "do the reverse of what they should do". In
reality, Peter, it is your expectations that are incorrect. Since I
have seen this problem in a number of applications, I'd like to remind
X application writers that:
----------------------------------------------------------
|GXset and GXclear will NOT yield consistent results across|
| all X server displays!!! |
----------------------------------------------------------
They put the values 1 and 0, respectively, onto the screen. Most
displays interpret 1 as Black and 0 as White, which is what people seem
to expect. This is why "the sun works correctly". Other displays, like
the Visual 640 (and, evidently, IBM's apa16) represent Black as 0, with
the result that GXset and GXclear do the reverse of what people expect.
Hence, the use of these functions in applications which expect widespread
use is as bad as setting the foreground and background pixel values to a
hardcoded 1 or 0, rather than using the BlackPixel() and WhitePixel()
macros. Please don't do it!!!
--------------------------------------
Christian Reimer
Visual Technology (XPI Division)
ctr@xpiinc.uu.net | uunet!xpiinc!ctrjim@EXPO.LCS.MIT.EDU (Jim Fulton) (03/16/89)
I'll be even more emphatic: People need to remember the difference between bit masks (containing boolean values of 1 and 0) and pixmaps (containing pixel values such as WhitePixel, BlackPixel, 42, 87, or any other number). "Bitmap" files (such as those created by the bitmap program are actually bit mask files. If you want to generate a depth-1 pixmap from them, you need to do something like XCreatePixmapFromBitmapData or XmuCreatePixmapFromBitmap. If you blindly assume that you can use them directly, your program will break on many, many displays. Anyone who assumes that BlackPixel or WhitePixel have particular values (this includes doing boolean operations without making sure that the resulting values will all be well known) are dead wrong. Hmm, maybe the sample server ought to randomly choose which values to use for BlackPixel and WhitePixel.... :-)
dheller@cory.Berkeley.EDU (Dan Heller) (03/17/89)
In article <8903161458.AA28597@expo.lcs.mit.edu> jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > >I'll be even more emphatic: > >People need to remember the difference between bit masks (containing boolean >values of 1 and 0) and pixmaps (containing pixel values such as WhitePixel, >BlackPixel, 42, 87, or any other number). ... >Anyone who assumes that BlackPixel or WhitePixel have particular values >(this includes doing boolean operations without making sure that the >resulting values will all be well known) are dead wrong. Let me further warn anyone who is implementing a server based on the Sun server... if your display has the screen "flipped" with respect to the Sun monochrome screen, you can't just "reverse" the values of 0 and 1 for WhitePixel and BlackPixel and expect the server to work properly. I've now had -two- experiences dealing with hardware in which the people who implemented the server decided to flip the values of white and black and cover up for it by interting the GX* functions as described in X.h That is, GXclear had "1" instead of "0" and GXset had "0" instead of "1" and all the function inbetween were "logically swapped" so that the boolean logic would appear to come out right to compensate for the swapped values for WhitePixel and BlackPixel. This does *not* work! Masking operations will fail and you will get all sorts of weird results. Dan Heller <island!argv@sun.com>
clive@ixi.UUCP (Clive) (03/20/89)
In article <8903161458.AA28597@expo.lcs.mit.edu>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > Hmm, maybe the sample server ought to randomly choose which values to use > for BlackPixel and WhitePixel.... :-) A very good idea (no smiley or sarcasm). The best way to make people adhere to standards is to make the consequences of not doing so too much effort - changing the value of #defined symbols regularly (yes, I know they're not #defines, but the same principle holds) is a good way to do this. -- Clive D.W. Feather clive@ixi.uucp IXI Limited ...!mcvax!ukc!acorn!ixi!clive (untested) +44 223 462 131