wwb@sps.com (Bud Bach) (10/05/90)
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. My test program works fine on both color and mono MIT X11R4 servers on Sun 3/60's. 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?-- Bud Bach Voice: 407 984-3370 Software Productivity Solutions, Inc. FAX: 407 728-3957 122 4th Avenue email: wwb@sps.com Indialantic, FL 32903 or: ...!uunet!sps!wwb
marbru@auto-trol.UUCP (Martin Brunecky) (10/07/90)
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. > >My test program works fine on both color and mono MIT X11R4 servers on >Sun 3/60's. > >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, 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 -). -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
caag@inf.rl.ac.uk (Crispin Goswell) (10/09/90)
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
marbru@auto-trol.UUCP (Martin Brunecky) (10/10/90)
In article <10309@nfs4.rl.ac.uk> caag@inf.rl.ac.uk (Crispin Goswell) writes: >In article <862@auto-trol.UUCP> marbru@auto-trol.UUCP (Martin Brunecky) writes: >>In article <277@sps.com> wwb@sps.com (Bud Bach) writes: >>> >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. > Xor on DECstation 3100, 8-plane color, ULTRIX 4.0 works right. (I can't guarantee it for other modes -) >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). ..... >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. > Interesting concept. Thanx. However, for my rubberbandings I can't afford to do things twice. With size and/or complexity of my animations the intermediate artifacts become too visible to annoy the user. As a simple example, (in the past) we tried to drag around a Color pixmap. Save area, blit my picture on it, restore, blit in a new position. It did work, but even when we minimized number of saves by pre-saving larger areas, it just did not fly. Xor looks much better, especially when you can pack undraw/draw new position into a single protocol request (draw segments), but even two copy area/planes followed by flush do well. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404