home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / windows / x / 14599 < prev    next >
Encoding:
Text File  |  1992-07-29  |  1.3 KB  |  36 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
  3. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  4. Subject: Re: GXcopy and GXxor
  5. Message-ID: <1992Jul30.000839.5722@thunder.mcrcim.mcgill.edu>
  6. Keywords: GXcopy and GXxor
  7. Organization: McGill Research Centre for Intelligent Machines
  8. References: <xia.711911424@odin>
  9. Date: Thu, 30 Jul 92 00:08:39 GMT
  10. Lines: 25
  11.  
  12. In article <xia.711911424@odin>, xia@molbio.ethz.ch (Xia Tai-he) writes:
  13.  
  14. > I have created a GC with function GXcopy and another GC with GXxor
  15. > for drawing rubber-band lines,
  16.  
  17. > I also set the foreground colors for the two GCs.
  18.  
  19. What did you set them to?  Getting the foreground pixel value wrong is
  20. the commonest problem with GXxor.
  21.  
  22. > However, the lines drawn with the second GC don't have the color I
  23. > have set, whose colors differ depending on the objects alreay
  24. > existing on the screen.
  25.  
  26. That's the way GXxor works: it XORs the foreground value in the GC with
  27. the value that's already there.  It's up to you to make sure that the
  28. result is what you want.  (XOR is useful for rubber-band lines because
  29. it's easy to invert - it's self-inverse.  But of necessity, this means
  30. that different pixel values underneath the rubber-band end up being
  31. different pixel values when rubber-banded over.)
  32.  
  33.                     der Mouse
  34.  
  35.                 mouse@larry.mcrcim.mcgill.edu
  36.