home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
- From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
- Newsgroups: comp.windows.x
- Subject: Re: The GC in XCopyPlane
- Message-ID: <1992Nov20.095230.20490@thunder.mcrcim.mcgill.edu>
- Date: 20 Nov 92 09:52:30 GMT
- References: <IDF.92Nov13023005@fat-controller.cs.bham.ac.uk>
- Organization: McGill Research Centre for Intelligent Machines
- Lines: 34
-
- > Distribution: comp
-
- Please don't misuse newsgroup hierarchy names as distributions.
-
- In article <IDF.92Nov13023005@fat-controller.cs.bham.ac.uk>, idf@cs.bham.ac.uk (Ian Fitchet) writes:
-
- > Being a pseudo-ignoramous I merrily copied the code from O'Reilly
- > Vol4 involving XCopyPlane. All was well until I actually tried the
- > code out on a colour monitor (worked fine on a monochrome - the
- > XCopyArea bit). [used own gc rather than screen default gc]
-
- > [ Code showing how gc in use was created, with "pixmap" as the
- > drawable in the XCreateGC call. We are not shown anything else
- > about this object. ]
-
- > [This gc] differed in only two respects from the GC returned by
- > DefaultGCOfScreen(). Firstly, it had a different gid (== GC id??)
- > and secondly the values of foreground and background were reversed.
-
- I suspect it also was only one bit deep, whereas the default GC was as
- deep as the default visual (probably 8 bits). The GC you create will
- be as deep as "pixmap"; you didn't show enough code for me to determine
- how deep this is, but I suspect it's only one bit.
-
- > When I invoked XCopyPlane with my GC I had a BadMatch error.
-
- This is normal if the GC is in fact not the same depth as the
- destination drawable - the GC you pass to XCopyPlane must be compatible
- with the *destination* drawable, not the *source* drawable.
-
- der Mouse
-
- mouse@larry.mcrcim.mcgill.edu
-