Path: utzoo!attcan!uunet!mcsun!ukc!warwick!rlnfs4!caag From: caag@inf.rl.ac.uk (Crispin Goswell) Newsgroups: comp.windows.x Subject: Re: Rubberbanding woes too! Keywords: xor drawing decwindows Message-ID: <10309@nfs4.rl.ac.uk> Date: 9 Oct 90 11:09:49 GMT References: <277@sps.com> <862@auto-trol.UUCP> Reply-To: caag@inf.rl.ac.uk (Crispin Goswell) Organization: Rutherford Appleton Laboratory, Informatics Department, U.K. Lines: 73 In article <862@auto-trol.UUCP> marbru@auto-trol.UUCP (Martin Brunecky) writes: >In article <277@sps.com> wwb@sps.com (Bud Bach) writes: >> >>Like a previous poster (Mark A. Horstman), I too am having problems >>with rubberbanding on a non-MIT server. The server is the DECWindows >>server that comes with VMS 5.3. H/W is a VaxStation GPX 4 plane >>monochrome. >> .... >>On the DECWindows server there appears to be a problem with drawing >>using xor mode -- no output. Copy mode works fine. Has anyone else >>observed this problem or am I doing something stupid?-- > > Most likely the last one. I have no problems with rubberbanding etc, You may be jumping to conclusions here. The last DECwindows server I used (Ultrix 3.? DECstation 3100, 8-plane color) had a bug with Xor mode. It seemed to perform a GXequiv instead of GXxor. GXequiv works as expected. I've not reported this because we do not have Ultrix 4.0 yet. > but most people who do NOT think what Xor mode does, and ASSUME > that all servers will use pixels 0,1 as black and white GET BURNED. > > All you have to do is: > drawing_pixel = background_pixel Xor desired_rubberband_foreground. > and then draw or copy plane or... using Xor mode and drawing_pixel. > > Naturally, you get different color where you cross non-background, > but you can't have it all for that cheap -). We use some unusual techniques which are related to this, and may be of interest. We have many applications which do clever things with monochrome rasterops using a locally written graphics library. (masking, Xoring, highlighting by GXinvert, etc). Rather than re-write them all to use color (we don't want color - we just find we have to support these damn things sometimes :-), we simulate monochrome rasterop on color. "Impossble!" I hear you say? Not so. Assume we have two random pixel values for foreground and background. Since this will be imposed anyway, we can make these configurable. Some bits of the foreground will be set where the background is clear (i.e. fg & ~bg) and/or some bits of the background will be set where the foreground is clear (i.e. bg & ~fg). Usually only one of these will contain set bits, but when they both do, two graphics requests will be necessary, one with the given alu function and a planemask containing the bits in the first case, and one with the inverse of the alu function (e.g. for GXcopy use GXcopyInverted) and a planemask containing the bits from the second case. Using this technique, we have applications which only require two colors, but use most of the 16 possible alu functions, and which behave identically in monochrome and in color. Name: Crispin Goswell |-------|__ Informatics Department UUCP: {... | mcvax}!ukc!rlinf!caag | Tea | | Rutherford Appleton Lab JANET: caag@uk.ac.rl.inf \ Mug /_/ Chilton, Didcot ARPA: caag%inf.rl.ac.uk@nsfnet-relay.ac.uk \_____/ Oxon OX11 0QX, UK "Nothing is the same thing twice, Which doesn't mean two things the same are not." - Peter Blegvad -- Name: Crispin Goswell |-------|__ Informatics Department UUCP: {... | mcvax}!ukc!rlinf!caag | Tea | | Rutherford Appleton Lab JANET: caag@uk.ac.rl.inf \ Mug /_/ Chilton, Didcot ARPA: caag%inf.rl.ac.uk@nsfnet-relay.ac.uk \_____/ Oxon OX11 0QX, UK "To avoid trouble. I quickly abolish fires, garbage, and also mail, which after all never brings anything but problems." - Italo Calvino