Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!cory.Berkeley.EDU!dheller From: dheller@cory.Berkeley.EDU (Dan Heller) Newsgroups: comp.windows.x Subject: Re: Beware the non-portable GX functions... Summary: server writers take note! Keywords: WhitePixel, BlackPixel, etc... Message-ID: <11201@pasteur.Berkeley.EDU> Date: 17 Mar 89 07:53:27 GMT References: <8903152321.AA00859@bird.xpiinc.uu.net> <8903161458.AA28597@expo.lcs.mit.edu> Sender: news@pasteur.Berkeley.EDU Reply-To: dheller@cory.Berkeley.EDU.UUCP (Dan Heller) Organization: University of California, Berkeley Lines: 27 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