| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1985.1 | | FLUME::dike | | Tue Jan 02 1990 12:27 | 7 |
| Use a function which is its own inverse. GXxor is popular for this purpose.
Draw the lines, and draw them again before going to the next position. The
problem with this is that the color of the rubber-band is not guaranteed to
contrast with the background color or pattern.
Earlier in this conference you will find mucho discussion of this topic.
Jeff
|
| 1985.2 | Coordinating private colorcells with GXcopy; GXset; GXclr | FREZEN::PROJECTS | | Tue Jan 02 1990 16:55 | 3 |
|
Thanx
|
| 1985.3 | Try it this way... | EXLIB::DLUGOSZ | Open foot, Insert Mouth | Thu Jan 04 1990 13:39 | 12 |
| You want to set the gc functions like so:
GXset draw rubber-band line to make it visible
GXclear draw rubber-band line to make it invisible
GXcopy draw final version of line
Make sure that you use the plane mask returned by XAllocColorCells
when drawing with GXset and GXclear, otherwise the overlay won't
work properly.
Ron
|
| 1985.4 | Use GXxor | DAVIS::peter | | Thu Jan 04 1990 15:24 | 11 |
| The problem with using GXclear to erase your rubber-band line is that
is also erases any pixels which may have been set prior to your
rubber-banding. For example, if you sweep your rubber-band line across
a line that was drawn previously, parts of the earlier line will be erased.
That's the reason for using GXxor. It inverts each pixel when you draw
the rubber-band line, and then inverts again (ie, restored original
value) when you erase that line. For some strange reason, it's also
useful to set the fourground field in the GC to (WhitePixel ^
BlackPixel). I'm not sure why this works, but it seems to make a
difference on color systems.
|
| 1985.5 | It works. | EXLIB::DLUGOSZ | Open foot, Insert Mouth | Thu Jan 04 1990 20:49 | 13 |
| RE. -1
Not if you're using your planes masks properly it won't. The method
.0 is trying to use was designed for the purpose of nondestructivley
adding and removing overlays -> same general concept as rubberbanding.
The reason .0 is using this, if I remember from an earlier note,
is that he wants his rubberband line to remain a constant color
when drawn over different color objects.
I use it myself - it works.
Ron
|
| 1985.6 | | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Fri Jan 05 1990 17:16 | 11 |
| re .4: The reason that using WhitePixel XOR BlackPixel is useful is that if
you do that, only the bit(s) which are different between WhitePixel and BlackPixel
will change with an Xor. That means that anything which is drawn in WP will
be changed to BP and vice versa. If stuff is drawn in other then WP and BP,
it will only work by coincidence (if the fg and bg of what you are drawing
into happen to differ by the same bit as BP and WP).
.5 is really the only sure thing, and that only on Pseudo/DirectColor or
GrayScale device. Not TrueColor.
Burns
|
| 1985.7 | Coordinating private colorcells with GXcopy; GXset; GXclr | FREZEN::PROJECTS | | Mon Jan 08 1990 18:05 | 14 |
|
Thanx for the replies... I wish I could have used some of the ideas
especially the private color cell strategy but instead I developed
my own rubber band color line strategy.
I find out what the default background color is on the display is
and then I calculate a foreground pixel value by doing a software
XOR on the background color pixel and the current pixel value for
the color I intend to display and I use this new unknown foreground
pixel value as the foreground in my GC. Works great.
Much appreciated
Ken
|
| 1985.8 | Just to understand... | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Tue Jan 09 1990 17:12 | 6 |
| Are you using XOR writing mode?
I assume the only problem here will be that it does not necessarily get
any reasonable color when you rubber band over a foreground color.
Burns
|